Fedora 10 - Page 4

./89 -> C'est encore un bogue différent. Apparemment il adapte automatiquement l'indentation de la ligne d'après à celle d'avant, qui est 0 parce que tu viens de l'insérer...
./90 -> Es-tu sûr que tu n'as pas activé l'option d'utiliser la touche tab pour indenter?

Kevin Kofler (./91) :
./89 -> C'est encore un bogue différent. Apparemment il adapte automatiquement l'indentation de la ligne d'après à celle d'avant, qui est 0 parce que tu viens de l'insérer...

Et c'est normal que ça fasse ça avec l'auto-indent désactivé ?!?

Sinon : Fichier joint : (indentation)

t1 je me tape un autre master bug d'édition (il aime pas les lignes de plus de 200 caractères ou quoi ?), mais j'ai pas envie de poster mon cde top secret et vaporwareux

Et c'est trop dur à expliquer tellement ça fait n'importe quoi (mais en gros un DEL sur une ligne me fait un retour charriot au début de la précédente + un ajout de tabulation + je sais pas quelle merde encore, une annulation fait que ça continue à déconner sec etc... )

hé, dites : merci Emacs de m'avoir tiré de la merde, il est spartiate mais bug pas ce machin.

Nouvel autre bug. Quand on "externalise" ou "dédock" la barre d'outil (je l'avais mise sur la même ligne que le menu, pour ne pas perdre de place en hauteur, elle était "posée par dessus), elle reste au-dessus même quand on switche vers une autre application

On est 5 minutes avant Noël, et t'as rien de mieux à faire qu'à coder sur TI ?

(quoi, moi non plus ? euh... )

Zerosquare (./95) :
On est 5 minutes avant Noël, et t'as rien de mieux à faire qu'à coder sur TI ?

Papa Noël, donne-moi un KDE 4 et un TiEmu bug-free !

Bon, apparemment tous tes bogues de Kate ne sont pas les mêmes que ceux que je connais, je te conseille d'aller faire un tour sur https://bugs.kde.org/ pour les reporter aux auteurs upstream. J'espère qu'ils seront traîtés plus sérieusement que ce que j'ai reporté.

C'est bien ce qui est emmerdant, c'est quand tu te prends un "Not a bug, won't fix", alors que tu constates le bug gros comme ça.

Ne t'inquiète pas, ils ne vont pas te dire "Not a bug, won't fix", ils vont juste l'ignorer.

Folco (./39) :

Mais les updates n'avaient pas non plus besoin de root, tu te rends compte ?

Ca, je peux le comprendre. Les updates, c'est ce qui permet d'avoir une machine sûre, et si ça permet d'éviter qu'un root passe sur chaque machine dans un parc important pour chaque mise à jour de sécurité, ça me va.

Kevin Kofler (./56) :

Puis de toute façon, ce n'est pas à l'utilisateur d'installer des choses uniquement à l'admin

Ben si l'utilisateur connaît le mot de passe root, c'est qu'il est l'admin! Redemander le mot de passe ne sert qu'à éviter que des chevaux de Troie installent n'importe quoi automatiquement, ils ne peuvent pas faire ça parce que seuls les paquetages signés par une clé de confiance sont autorisés. (Et c'est aussi ça la différence avec sudo sans mot de passe: les actions permises sans le mot de passe sont très limitées et spécifiables précisément même si elles sont performées par le même outil graphique - avec sudo, tu ne peux qu'autoriser ou interdire des commandes, donc en l'occurrence l'outil graphique entier.)

Là, par contre, je ne suis pas d'accord (du tout). Je ne sais pas comment fonctionne le système (s'il enregistre le mot de passe root crypté ou s'il donne un certificat particulier à un utilisateur qui a connu le mot de passe root), mais un utilisateur qui a connu une fois le mot de passe root peut très bien ne plus avoir à le connaître à t+1 (s'il a fait une bêtise, on change le mot de passe sans le lui redonner, par exemple).
Autre hypothèse : un administrateur vient sur la machine d'un utilisateur. Celui-ci a un gros travail en cours. Vu que X11 ne permet pas la gestion de sessions concurrentes (enfin, surtout que les distribs courantes ne permettent pas simplement d'avoir plus d'un X lancé à la fois), si l'administrateur a quelque chose à faire en tant que root (mise à jour, reconfig, install de paquetage), il peut avoir à le faire dans la session lancée. Donc il donne (sans le savoir s'il n'est pas au fait de la subtilité - quand je parle d'administrateur, ça peut être des opérateurs ou des pupitreurs qui ne sont pas des gourous de la sécurité) sans le savoir un droit assez conséquent à l'utilisateur.
Ca peut sembler dérisoire vu que ce sont des "paquets signés" donc théoriquement sûrs. Mais si un usager se met à installer sur son poste des centaines de services, pas sûr que ça soit apprécié.

Nil (./100) :
Je ne sais pas comment fonctionne le système (s'il enregistre le mot de passe root crypté ou s'il donne un certificat particulier à un utilisateur qui a connu le mot de passe root)

2^ème solution. Enfin presque. Ce qui se passe, c'est que ce sont des capabilités et que ça enregistre dans une BDD centrale que tel utilisateur a telle capabilité.

mais un utilisateur qui a connu une fois le mot de passe root peut très bien ne plus avoir à le connaître à t+1 (s'il a fait une bêtise, on change le mot de passe sans le lui redonner, par exemple).

Tu peux virer toutes les capabilités PolicyKit pour l'utilisateur en question facilement (il y a des logiciels graphiques polkit-gnome-authorization et polkit-kde-authorization qui permettent de le faire facilement).

Autre hypothèse : un administrateur vient sur la machine d'un utilisateur. Celui-ci a un gros travail en cours. Vu que X11 ne permet pas la gestion de sessions concurrentes (enfin, surtout que les distribs courantes ne permettent pas simplement d'avoir plus d'un X lancé à la fois)

Si, il est facile d'ouvrir une deuxième session X11 en tant qu'un autre utilisateur, à condition d'utiliser display manager et desktop qui vont ensemble (GDM avec GNOME, KDM avec KDE).

si l'administrateur a quelque chose à faire en tant que root (mise à jour, reconfig, install de paquetage), il peut avoir à le faire dans la session lancée. Donc il donne (sans le savoir s'il n'est pas au fait de la subtilité - quand je parle d'administrateur, ça peut être des opérateurs ou des pupitreurs qui ne sont pas des gourous de la sécurité) sans le savoir un droit assez conséquent à l'utilisateur.

Il y a une case "Remember authorization" qu'on peut décocher.

Ca peut sembler dérisoire vu que ce sont des "paquets signés" donc théoriquement sûrs. Mais si un usager se met à installer sur son poste des centaines de services, pas sûr que ça soit apprécié.

Les services sont en général désactivés par défaut même si on les installe, il faut le mot de passe root aussi pour les activer. (Mais system-config-services va aussi utiliser PolicyKit un de ces jours.)