1) Ne pas utiliser GMail, c'est du caca
2) Faire des copies des mails important

Et accessoirement:

3) Vas faire un tour dans les réglages de GMail, doit y avoir une option pour supprimer les messages tout les x jours/mois/whatever

Nh3xus: Monster, c'est du c aussi hein.

liquidus > eh ouai mais gmail c'est ce qui me fout quand même le moins d'ennuis en général. C'est diabolique mais je peux pas m'en passer
Les mails étaient pas importants (ils sont marqués important automatiquement quand j'envoie certaines pièces jointes), normalement je fais moi-même mon tri et j'arrive à peu près au même résultat, c'est juste que ça m'a fait flipper.

J'ai regardé les réglages de gmail, et aucune option à ce niveau-là. J'ai pas ça non plus dans mon muttrc, faut que je vois si ça vient pas d'Icedove parce que je l'ai justement lancé hier pour voir un truc... mais ça attendra une semaine, j'ai pas mon fixe avec moi

Go GMX, c'est très bien

autistici c'cool aussi hein.

J'ai pas dis le contraire, juste que GMX est très bien

C'est kwa ces logiciels

+Si quelqu'un a des SlackBuilds à faire tester, je pourrais faire ça demain

Non, c'est bon. Y'a juste rxvt-unicode qui veut pas compiler avec le support de perl.

Putain je me suis encore fait traquenarder par le fameux "mais nan tu le feras plus tard" et un rapport en expliquant en détail du code assembleur d'il y a un mois c'est vraiment une punition.
(heureusement que je l'ai plutot bien commenté)

Faut que je test DWM

Moi j'ai pas le temps d'écrire des Slackbuilds mais ça tombe bien, on en trouve pas mal sur Github

Je modifie des scripts existant pour deux raisons :

ça va plus vite

c'est moins compliqué

J'ai pas le temps de me mettre aux regexp, à sed, awk, xargs et j'en passe.

Pourtant, j'aimerais bien parfois.

f0c300 M'en parle pas de l'assembleur

C'est trop bien de programmer des PIC16F

Knakis J'ai survolé le repo Github de Monsterwm.

Je testerais à l'occasion.

Mais c'est horriblement frustrant de pas avoir de temps...

Ils nous ménagent pas en L3

Je cherche à connaitre le temps que met un logiciel à s'ouvrir.
Je pense donc à la commande 'time'.
Exemple :
time smplayer
real 0m2.555s
user 0m0.138s
sys 0m0.023s

Alors ok pour 'real' qui est à laisser de côté car c'est le temps passé dessus (ici juste lancé et fermé).
Mais ensuite pour ce que je veux, je pense qu'il faut prendre en compte 'user' non ? Ou additionner 'user' et 'sys' ?

Ouais c'est rigolo les PIC16F

Mais 200 lignes de code en 16h (dont 14 passées à lire la doc) pour un truc tout crétin c'est un peu frustrant au final quand même.

Bon, quand t'as des macros pour changer de bank par exemple, c'est tout de suite plus agréable

Après ouais, c'est surtout l'apprentissage qui était plus que fastidieux, je pense qu'à refaire ce sera déjà moins galère.

Les gars, quelqu'un à déjà réussis à faire tourner Daggerfall sous DOSbox Linux ? Parce que je monte bien le lecteur D: sur DFCD et mount me montre clairement que je l'ai monté et CDRom etc... mais le jeu me dit toujours que j'ai pas le CD d'inseré

Lord-Valfar, times mesure trois choses differente. Tout depend de la quelle est pertinente pour ce que tu veux faire.

Ah bah si, ça marche

Oui godrik y a bien 3 choses, justement 'real' ne m'est d'aucune utilité car il mesure le temps qu'on a passé dessus.
Ce qui m'intéresse c'est uniquement le temps que met le soft à se lancer.
Donc, est-ce uniquement 'user' à prendre en compte ou pas ?
De ce que j'avais lu, 'user' ne touche pas (façon de parler) au noyau, c'est 'sys' qui fait ça, d'où ma question aussi si il ne faut pas additionner les valeurs de 'user' et 'sys' donc ?