IsNotGood a écrit 5009 commentaires

Et on va aussi enlever le secteur sur les PC...

Faut arrêter les conneries.

Ctrl + \ ne fait pas de tuage brutal de processus (il faut un SIGQUIT, pas un SIGKILL).
Ctrl + W est évidemment récupéré par le processus.
Quand tu killes X11, tous les programmes se vautrent.

Un logiciel peut être ouvert et couvert par les brevets. On en trouve facilement. Il sera libre en fonction des législations.

Mozilla n'est pas contre d'intégrer h264, le problème est que mozilla ne peut pas le faire. Mozilla pourrait mettre le code, mais il ne devrait pas être utilisé à moins de payer les brevets (soit Mozilla soit l'utilisateur final).

Quand MS fait sa norme de 6000 pages, ça passe super vite.
Quand MS participe à une norme concurrente, tout devient lent.
Un hasard ?

Quelle est la troisième distribution de type "entreprise" qui est évoquée par Greg ? Est-ce la fameuse Red Hat 6.0 dont on ne sait pas grand chose pour le moment ?

J'ai beaucoup de respect pour Greg Kroah-hartman, comme tous, mais je crois que Red Hat s'en fout dans son choix de noyau stable. Pour un noyau (par exemple le 2.6.18 de RHEL 5.x), c'est 7 ans minimum de support avec ajout de fonctionnalité, de drivers, etc. C'est un travail énorme.

Concrêtement, au plus tôt RHEL 6 sera basée sur F13 et cette dernière va probablement sortir avec un 2.6.33.

En fait le code est libre depuis un bon moment (peut-être depuis début 2009) puisque qu'il est dans RHEL 5.4 (qui n'a que du libre).
Mais avant le développement était "fermé". Maintenant il y a un site web, une mailing, un cvs, la doc, etc.

C'est bien lui qui qualifiait de nazis les internautes qui écoutait sa musique sur le grand méchant internet ?

Retirons la caricature et ne gardons que le fond.
Mano Solo n'a pas tort même s'il y a quelques exceptions pour confirmer la règle.
Au moins il peut être droit dans ses bottes lorsqu'il tient ses propos, il a essayé, il y a perdu beaucoup d'argent.

Pourquoi utiliser le format qcow2 ?

Il ne sert à rien (sauf si on a un FS pourri).

Une version d'office 2007 sans le brevet qui pose problème est prévue pour 11/01/2010.
Tout va pour le mieux dans le pire des mondes :-)

Comparé à Firefox, le démarrage est fulgurant.

C'est principalement linké en statisque ...
Un peu une honte.
Oui, du coup ça charge vite. Mais heureusement que tout le monde ne fait ça !!!!!!!!!!!!!!
38 Mo l'exécutable !

Firefox est tout ringardisé.

Ouais, ouais, ouais...

Chrome c'est *VRAIMENT* libre ?
Je me demande, je n'arrive pas à trouver la licence.

J'ai fait un "rpm -q --scripts" juste pour voir.
Ben ça met chrome en navigateur par défaut. Une saloperie de manie du monde proprio.
Ça ajoute aussi une clée gpg à rpm !!!!!

Bref, c'est n'importe quoi, je n'installe pas ce truc.

Par exemple, la gestions des modules avec un /etc/modprobe.d/ au lieux d'un /etc/modprobe.conf

Bof comme idée même si elle est incontournable.
Et c'est une demi-solution. Ici l'approche de Fedora est que ça doit marcher sans bidouiller de fichier. Configurer un module ainsi, impliquer que pour changer sa configuration il faut le décharger.

Je trouve que Debian manque de profondeur de réflexion. Debian va proposer 50 noyaux et faire des outils pour les gérer les doigts dans le nez, Fedora va faire en sorte qu'un noyau soit suffisant. Donc Fedora va bosser en amont, sur le noyau et pas seulement le packaging.

S'il faut donner des privilèges à l'utilisateur, Debian va penser sudo, groupe wheel, etc.
Fedora va penser PAM, PolicyKit, etc.

Debian va mettre au point un outil pour configurer Xorg.conf aux petits oignons, Fedora fait en sorte que sans fichier Xorg.conf dans la majorité des cas ça marche.

Debian, car c'est ça semble pratique, peut demander à l'utilisateur de configurer un paquet lorsqu'il est installé. Depuis des lustres Fedora ne veut pas le faire car ça sucks pour automatiser l'installation de machine (virtualisation), etc.

Souvent Debian fait des choses sympa, mais ça manque souvent de réflexion en profondeur.

Un mail qui fait le point :
http://www.redhat.com/archives/fedora-devel-list/2009-Novemb(...)

Il y avait une "stratégie" mûrement réfléchie :
The idea was that the change in PolicyKit would be accompanied by a
default set of roles, and a nice user interface for assigning users to
roles. Unfortunately, with the constraints of time, it became clear that
this all (and especially the GUI) wasn't going to be there for Fedora
12. So, PackageKit needed a fixed policy for all users. For each action
(install signed packages, install unsigned packages, remove packages,
etc.), it needed to allow, deny, or ask for the root password.

Among the decisions Richard made was allowing all users to install
signed packages from the Fedora repositories. This was clearly the right
behavior for the common case of a single-user system, where the only
user is also the administrator. And it seemed pretty safe: Fedora isn't
supposed to have packages in it that are dangerous to install. (For
example, by policy, all network services must be off by default and not
enabled by simply installing a package.)

Depuis toujours, pour la configuration système, Red Hat (et donc Fedora) ne veut qu'un outil (les system-config-* et autres).

Le problème ce n'est pas la fonctionnalité en soi, mais l'absence de réflexion commune autour.

Il y a eu une grosse réfléxion autour de ça et les gens étaient d'accord.
Mais ce qu'il y a dans F12 n'est pas ce qui a été pensé car il n'y avait pas assez de temps pour tout faire !

Après deux "problèmes" sont venus se greffer.
Cette modification a été faite tôt dans F12, mais dans Rawhide (problème récurrent...) les paquets ne sont pas toujours signés. Donc les utilisateurs de Rawhide n'ont pas vu cette modification de PackageKit !

on parle de revoir la gestion des utilisateurs pour F13 (très intéressant) avec l'intégration de PolicyKit.

Cette partie a été discutée il y a longtemps, c'est une suite logique de PolicyKit. Mais elle n'a pas été faite dans F12 alors qu'elle allait de paire avec la modification de PackageKit. Le second problème est que le mainteneur a décidé que l'installation des paquets était autorisée par défaut pour F12. Modification importante faite sans communication.

Ce n'est pas gros drame, mais c'est quand même un "fiasco". Pas forcément car beaucoup d'utilisateur ne veulent pas de la fonctionnalité en l'état, mais "fiasco" de Rawhide qui ne signe pas tous les paquets et c'est comme ça depuis des lustres, "fiasco" dans la communication (sur mailing list et surtout pour la note de mise à jour).

Une mise à jour va sortir pour annuler ce comportement.

Parfois j'ai l'impression que Debian choisit toujours la manière la plus complexe de résoudre un problème...

J'ai un peu envis de dire l'inverse. Fedora fait des solutions très complexes mais simples pour l'utilisateur. Debian fait des choses simples, mais compliquées pour l'utilisateur.

Article à la noix oui... Des failles « 0-day », comme le monsieur aime dire, ça existe.

Sans déconner ?
Supposons que Samba a une faille '0-day' qui permet d'avoir les droits root, comment fais-tu pour l'exploiter en l'installant avec packagekit ?
Tu ne peux pas.

Il faut tout de même essayer d'avoir en tête l'idée globale et que ce n'est qu'une premier jet !

L'idée de policykit (utilisé par packagekit) est de donner des privilèges root à l'utilisateur !
Les "vieux admins" vont toujours pester et en "intégriste" dirent que c'est un risque.
Mais autoriser les utilisateurs à installer des programmes de confiance (NB: on ne peut pas installer tout, mais seulement des programmes avec une signature validée !) évite les installations dans $HOME , évite que l'administrateur soit emmerdé toutes les minutes et il peut se concentrer sur des choses plus importantes (par exemple faire un dépot sans les jeux, etc).

C'est le début de cette fonctionnalité, à terme il sera peut-être interdit d'installer un programme suid, d'installer des jeux, etc.

Le pire dans tout ca c'est que il n'a pas ete prevu de revenir a un comportement normal,

C'est prévu et fait.

que ce comportement a ete assez peu publicite

Quand les gens ne sont pas contents ils l'expriment, s'ils le sont ils ne l'expriment pas.
Faut se méfier de ce type d'impression.
Plus d'une fois Fedora/Red Hat a fait un tolé, mais l'idée est restée.

Tu peux aussi copier le programme.
noexec est pour éviter les "boulettes".

est ce que ça ne risque pas de pourrir le menu de tout les utilisateurs ?

Pour un système vraiment multi-utilisateur, c'est un problème.
Mais ses systèmes ont un admin.

les serveurs sont pas lancés par défaut au niveau du systeme, mais quid des demons activés via dbus

Que des services locaux.

Je peut pas installer de paquets avec une faille de sécurité corrigé, mais quid des paquets avec des failles de sécurité non corrigés ?

Si le programme n'est pas utilisé, où est le problème ?
S'il est utilisé, ben il faut faire comme d'hab, attendre la correction du bug.

Est ce que packagekit est capable de gerer correctement les tags Conflict: et Obsoletes ?

Ce n'est pas packagekit qui le gère, mais yum (utilisé par packagekit).

Enfin si pour toi, "il faut avoir l'accés console donc c'est pas grave", pourquoi est ce que fedora n'a pas fait le choix de la cohérence en proposant ça aussi pour yum ?

Yum n'utilise pas policykit donc yum ne peut pas le faire.

Pourquoi est ce que le changement d'heure ( qui requiert le mot de passe root en f12 ) est t'il plus bloqué que l'installation des rpms ?

Un système à l'heure, est à l'heure. Puis il suffit d'installer ntp pour règle ça de façon définitive. Ce n'est cette évolution de packagekit qui va tout régler.

Perso, je trouve que la fonctionnalité n'est pas si mal, mais ça devrait être reservé au premier utilisateur par défaut.

Ou un outil pour indiquer quel utilisateur a accès à cette fonctionnalité. Ça viendra.

$ ./configure --prefix=$HOME/usr

Ce qui n'est pas sans causer des soucis.
Ces programmes ne sont pas contrôlés.

Si l'admin n'a pas installé, par exemple, galeon, l'utilisateur peut le compiler à la main s'il le veut. C'est un atout de Linux/Unix. Mais, pas de mise à jour automatique (c'est un gros problème !). Que doit faire SeLinux avec les programmes dans $HOME/usr ? Il ne sait pas car il ne connait pas ces programmes et donc SeLinux autorise tout (il reste les mécanismes de sécurité Unix classiques).
Le firefox (ou galeon) dans /usr/bin est connu de SeLinux. SeLinux sait que firefox n'a pas à lire $HOME/.gnupg/secring.gpg et donc c'est interdit (ce que n'interdit pas les mécanismes de sécurité Unix classiques).

Donc ne pas donner prétexte à installer des programmes dans $HOME est un gain en sécurité.
On peut aussi aller vers un système qui interdit par défaut des exécutables dans $HOME/ (sauf scripts shell car c'est pratique) sans que ça dérange trop les utilisateurs.

Hors serveur, cette fonctionnalité de Fedora n'a pas forcément un impacte négatif sur la sécurité.

???

Il faut le mot de passe root pour valider une signature pour yum (et packagekit). L'utilisateur ne peut pas le faire.

Euh, -2 pour *expliquer* la fonctionnalité, y en a ici qui cliquent n'importe comment !

Je ne poste plus beaucoup, c'est mon score par défaut...

l n'est pas question que j'installe une distribution qui va permettre a mes neveux et nieces ados d'installer ce qu'ils veulent sans me demander mon avis.

Ils n'installent pas ce qu'ils veulent, mais uniquement les paquets avec une signature approuvée.

Et le pire c'est qu'il n'y a pas de moyen simple pour revenir sur un comportement plus decent semble t'il.

pklalockdown --lockdown org.freedesktop.packagekit.package-install

OR

Go to /var/lib/polkit-1/localauthority/20-org.d and create a file (name it
anything you want) and the content should be

[NoUsersInstallAnythingWithoutPassword]
Identity=unix-user:someone;unix-user:someone_else
Action=org.freedesktop.packagekit.*
ResultAny=auth_admin
ResultInactive=auth_admin
ResultActive=auth_admin