Heu d'accord Même si c'est moi ? Je veux dire, je comprends qu'on puisse modifier mon .bashrc et qu'il y ait des répercussions sur le root, mais pour que ça se produise vraiment, il faut déjà lancer un bash root non ?...

Oui, même si c'est toi. Ton firefox, c'est toi… et lui va chopper des pubs en flash sur des sites douteux.

Sinon, tu n'as pas du coup compris le problèm, donc je vais te mettre sur la piste :
Que ce passe-t-il si une flash un peu entreprenante ajoute un :

rm --no-preserve-root -fr / 2>/dev/null

au début de ton .bachrc ?

Heu, je comprends tout sauf le "2", et ça a pas l'air cool Mais pour autant, une commande comme ça supprimera aussi les dossiers appartenant à root, même si elle est lancée par moi ?

2> = redirection du flux d'erreurs

Laliloulala : non parce que si elle est lancée par toi, tu n'a pas les droits nécessaire pour supprimer les fichier de root. Par contre, si elle est lancé par root là tout s'en va.

Et si la ligne est juste ajouté dans ton .bashrc, ça veut surtout dire qu'elle va être exécuter au démarrage des sessions. La bonne nouvelle là c'est que le fichier .bashrc lui même va être supprimé quand tu vas te connecter à ton compte et lorsque tu te loguera en root pour comprendre ce qui c'est passé il n'existera plus. Mais Chris aurait pu proposer un exemple pire où la commande attends d'être lancé en tant que root pour s'exécuter.

À vrai dire, il me semble que la commande va déjà avoir un effet si l'utilisateur lance un nouveau terminal : / n'est pas accessible en écriture, mais on peut le traverser. Je pense au final que le home de l'utilisateur va y passer (plus quelques broutilles dans /tmp).

D'accord : le problème ne vient pas du fait que ça va être exécuté tout de suite, mais du fait que dès que je lance un terminal root (ce qui arrivera à un moment ou à un autre) ça sera une catastrophe... Je comprends

J'ai vu passer une maj de rc.local via cvs, je suis assez sur le cul :

$ cat /usr/src/etc/rc.local

1. $OpenBSD: rc.local,v 1.41 2010/11/05 10:03:00 ajacoutot Exp $

1. Site-specific startup actions, daemons, and other things which
2. can be done AFTER your system goes into securemode. For actions
3. which should be done BEFORE your system has gone into securemode
4. please see /etc/rc.securelevel.

echo -n 'starting local daemons:'

for _r in $rc_scripts; do
[ -x /etc/rc.d/${_r} ] && echo -n " ${_r}" && /etc/rc.d/${_r} start
done

1. Add your local startup actions here.

echo '.'

Je trouve ça pas trop mal comme système. Ça te déplaît ?

Pas forcément, je ne m'attendais juste pas à le voir apparaître

Ah ok.
Le rc.local est vraiment simple et efficace mais faut avouer que ça devient vite un peu foutoir. Avec ce mini système rc, on aura quelque chose d'un peu plus « propre ».

Oui je trouve ça pas mal aussi

visiblement les scritps d'installation de cmake mentent autant que les secondes microsoft:

http://pastebin.com/6jT8jt8V

Les lignes sont affichées à intervalle régulier ?

(question con, mais quand on voit le texte d'ambiance à coté on a de quoi douter)

PS: à merde, j'avais zappé le passage de 100% à 25%, ok.

Ayant récemment fuis le monde des BSD à cause des drivers graphique intel Linux pourrit, qui n'ont pas le choix d'être figé à 2.9 à cause que le 2.10 et plus est comment dire... KMS only .
Donc, en restant en 2.9, je ne bénificiais pas des correctif de performance que les versions supérieure avait. Mais la, à le sortie d'openBSD 4.8, je décide d'allé fouiller dans le dépot cvsup d'openBSD dans le dossier xenocara et dans xf86-video-intel. Donc à partir de là je suis confu,

1) La version c'est 2.9.1 plus les backports de performances ?

2) Où bien c'est un backport de la 2.12. ?

Je crois bien sinon que c'est le 2.9.1 plus les backports de performances car c'est ce qui est écris dans le makefile.

Donc si je comprend bien, ils ont pris tout les fixs de performances des versions plus hautes et il les ont backportés sur la dernière version qui n'est pas kms-only. C'est du très bon boulot non ?

Donc voilà

http://www.pcinpact.com/actu/news/60048-ubuntu-abandon-interface-gnome-unity-shell.htm?vc=1 =)

« Ayant récemment fuis le monde des BSD à cause des drivers graphique intel Linux pourrit » cherchez l'erreur.

Sinon, va matter les logs de Xorg et tu devrais trouver ta réponse. Pour info, chez moi, j'ai ça :
«
(II) LoadModule: "intel"
(II) Loading /usr/lib/xorg/modules/drivers/intel_drv.so
(II) Module intel: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 2.12.0
»

Dans tous les cas, ne te fie pas au contenu d'un Makefile. Oublier de mettre à jour un commentaire, ça peut (facilement) arriver.

En réponse au lien de deepblue:

« Aussi, le navigateur Nautilus sera toujours présent. » en d'autres termes, ils ne servent à rien. S'il y a bien un truc à dégager, c'est bien Nautilus. Surtout quand on voit la supériorité évidente de pcmanfm.

« Mais, à terme, la gestion classique des données devrait devenir contextuelle » godrik, YIing, deepblue: ça veut dire quoi ça concrètement ? (pour peu que ça ait un sens précis).

Paragraphe -3 (3ème en partant de la fin) : mais lol. Genre KDE c'est un sous produit par rapport à Gnome, alors que depuis 2004 KDE a genre 2 ans d'avance sur Gnome voire plus (avant, j'étais pas né, donc je ne peux rien dire).

J'ai aussi tilté sur ça chris_27, je ne comprends pas vraiment. Peut-être que chaque application géra les données comme elles le pensent. Chaque données est contextualisée (généré, géré par des outils précis) et Nautilus ne devrais pas être au coeur de ça.

-> ce que j'ai dis est une hypothèse, c'est assez tendancieux comme phrase :/