Reprise du message précédent :

En gros sans @ il va attendre que le daemons soit lancé pour passer au suivant alors qu'avec sans attendre qu'il soit fini de lancer (utile pour les trucs qui prends plusieurs secondes à se lancer et qui servent pas pour d'autre daemon )

Petite question sur tes partoches btrfs, et tant que fsck.btrfs n'est pas dispo, t'as modifié quelque chose avec tune2fs (en espérant qu'il y ai un impact sur btrfs) ou dans ton fstab ?

 
   
 
Par contre, fl0ups a précédé quasiment tous ses daemons du @, même ceux qui sont n'en sont pas précédés dans la page Wiki du rc.conf (genre dbus ce qui me parait un peu dangereux ). Mais bon visiblement ça marche.    

 
C'est à dire ?
Tune2fs est spécifique à Ext2/3/4    
 
Je pige pas bien la question

 
Bon tu me rassures alors. Il ne reste plus qu'a attendre le 3.0.1
Mais comment ça ce fais? je croyais qu'il n'y avait pas plus de nouveauté que d'habitude dans le 3.0  

Il y a du avoir des changements coté ACPI et la 3.0.1 est déjà dans le repos core

je voulais dire le suivant

J'ai parlé trop vite pour tune2fs
Et pour le fstab, normalement on peut désactiver le fsck (6ème colonne à passer à 0).

Ben là vu qu'il n'existe pas de fsck pour Btrfs, je ne vois pas quel problème ça peut poser, rien ne sera lancé, c'est tout

Sur Arch ca ne semble pas poser de problème, mais sur debian ca coince, il en veut un (et j'ai aussi lu que le fsck.btrfs actuel n'accepte pas les arguments, ca recoince).

Je te confirme que ca marche ;-) J'ai fait la manip depuis plus d'un an et je n'ai pas constate de problèmes.
Je ne pense pas ça soit dangereux (par exemple pour dbus dans le pire des cas tu auras un message d'erreur au démarrage de gnome ou kde, mais la probabilité est faible qu'il n'ait pas fini de se lancer a ce moment la).
Et je trouve ça beaucoup, mais alors beaucoup moins flippant qu'e4rat

 
Chez moi :

 
Et aucun problème. J'ai mon tty très tôt, par contre, il faut encore attendre quelques secondes pour que Xorg se lance.
En revanche, j'avais diminué UDEV_TIMEOUT à 1 ( ) et je l'ai remis à 30 à cause de quelques failed.

 
Ca a l'air génial e4rat, je testerai ce soir après sauvegarde de ma partition système
edit : effectivement, le realloc me fait peur mais c'est basé sur une fonctionnalité noyau donc ça doit être stable normalement.

 
Je t'ai écouté et cette fois-ci au lieu d'utiliser Grub2-uefi, j'ai pris Grub2 tout court et ca marche impec !

Hello,
 
ceci n'est pas un troll mais comment se fait-il que j'aie aussi peu de problème avec mon archlinux? C'est super stable, pourtant j'ai installé une foulitude de paquets. J'ai n'ai connu que ubuntu (depuis la 4.10 jusqu'à la 8.10 je pense) mais ca plantait vachement plus (surtout lors des dist-upgrades).
 
Quelqu'un  a une autre expérience avec arch? des idées à avancer?
 
merci

J'ai trouve mon probleme lie a l'heure et la date, en fait systemd ne supporte pas localtime, il fallait me mettre en UTC, et apres c'est tout bon.
J'aurais du mieux lire la doc, mais si ca peut aider quelqu'un...

La seule utilité d'avoir l'heure du bios enregistrée en localtime est pour Windows (donc si tu as du dualboot quoi), sinon mieux vaut être en UTC dans tout les autres cas

C'est surtout dû à ça je pense... si tu fais de petits upgrades réguliers t'as moins de chances de péter un truc que lors d'un gros update de tout le système.

 
L'utilité, c'est de rendre impossible le changement automatique heure d'été, heure d'hiver de façon fiable  

Je viens d'installer e4rat, effectivement, ça boot plus vite, aucun soucis pendant la manip   Le realloc est bien passé même si je l'ai forcé avec -f   C'est surtout intéressant pour le lancement de kde.

Au cas ou cela interessent quelqu'un, ce fs est super pour moi:
http://romanrm.ru/en/mhddfs

et bien sur dispo sur aur:
https://aur.archlinux.org/packages.php?ID=24738

Oui il y a deja raid et lvm, mais ca c'est bien plus simple, ca fonctionne sans reconfigurer quoi que ce soit, et si un disque tombe en panne on perd uniquement les donnees dessus aucun impact sur le reste, ce qui est suffisant pour ce que je voulais.
(apres si j'avais les moyens et la place, je passerais plus en raid 5 mais bon, pour un HTPC c'est un brin excessif )

Bon, ma question n'est pas directement liée à Arch, mais on sait jamais : j'utilise le dock Daisy comme lanceur d'applis, et quand je lance Libreoffice, plutôt que d'avoir une des icones de Libreoffice dans le doc (writer, base, calc etc.), j'ai cet immonde "X" qui je suppose est l'icone de... X. Est-ce que quelqu'un saurait comment changer ça ?

Combien de temps pour le démarrage de kde avant / après?

Aucune idée mais le gain n'est pas si flagrant que ça, je suis loin de ce que certains disent avoir (temps divisé par 2).
En fait, quand Xorg se lance, je pense que e4rat n'a pas fini la phase de preload.  
Par contre, si mon boot est ralenti (un fsck) et que le preload est terminé, ça fait comme un chargement à chaud de kde (5 secondes).
J'aimerai bien savoir si je peux me permettre de modifier le fichier startup.log généré par e4rat-collect, je pourrai dégager quelques trucs parasites (plus de 5000 fichiers dans la liste)...
Par exemple, j'utilise le plasmoid cadre, donc il m'a mis les photos affichées sur mon bureau dans mon startup.log.

Bin oui c'est normal, il enregistre tout ce que tu lances pendant 2 minutes, donc si ton cadre se lance au démarrage de KDE, son chargement se retrouve dans le fichier de log et est en théorie accéléré.

http://mailman.archlinux.org/piper [...] 14039.html  

 
Je sais, j'ai tapé dans le startup.log à coup de grep -v  
 
 
 
Le support des signatures via gpg pour les dépôts Ca manquait vraiment et ça craignait vraiment beaucoup.

Je me souviens que çà avait fait polémique cette non signature des dépots sur Arch.
Assurément une bonne nouvelle cette nouveauté donc

Ça et un mini changelog lors des MaJ et ça sera parfait

 
Ouais, mais pitié, je veux pas que le système de package demande d'avoir un doctorat pour le comprendre comme apt avec deb helper  

Un doctorat pour faire apt-get update apt-get upgrade apt-get dist-upgrade ? franchement ?

Pour info, Firefox 6 est dans testing (y compris les langues).

 
Non je pensais plutôt à ça : http://people.debian.org/~srivasta [...] ripts.html
et ce genre de choses : http://www.debian.org/doc/manuals/maint-guide/

Pourquoi tant de haine ?

Utilisez-vous Strigi/Nepomuk? Dernierement ca me fait lagger gravement (surtout en I/O) et au final je ne m'en suis jamais servi de ce truc...
J'ai fini par desactiver Strigi, pas encore Nepomuk, on verra bien si un en moins suffit.

 
J'utilise nepomuk, sinon j'ai une pop-up au lancement de kde pour dire qu'il est arrêté    
Strigi indexe le contenu des fichiers, je suppose que ça se calme une fois qu'il a indexé le disque mais vu j'ai jamais attendu assez longtemps pour le savoir, trop long quand on a 250Go de fichiers.

Perso j'ai désactivé les deux, par contre c'est clair que c'est gonflant d'avoir la notification à chaque ouverture de KDE comme quoi ils ne sont pas fonctionnels ...

désactivés aussi, je supporte pas ces trucs

Euh je ne sais plus trop comment j'ai fait pour ne plus avoir la notification mais il me semble que c'est en changeant les droits d'écriture pour la base de données.
 
De mémoire, la BDD doit être dans .kde4/share/nepomuk (SVP quelqu'un peut confirmer) puis j'ai effacé le fichier. Ensuite j'ai interdit l'écriture dans le répertoire.
 
Si ça ne marche pas chez certains, je regarderais mon ordi ce soir.
 
NB: il faut arrêter les services d'indexation avant la manip' sinon la BDD revient.

Effectivement il y a une bdd dans le répertoire .kde4/share/apps/nepomuk/repository/main/, nommé soprano-virtuoso.db ainsi que des fichiers .lock, .pxa, .trx, .log sous le même nom, et un soprano-virtuoso-temp.db également.
 
Ensuite y'a a peu près la même chose sous .kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/ . Faut faire pareil ?
 
Je testerai ce soir pour voir de toute façon ...
 
Faut tout supprimer avant d'interdire l'accès au répertoire ?

Il me semble que si tu interdit l'écriture, tu ne peux pas supprimer.
 
Il possible aussi de copier les fichiers quelque part avant de faire la manip'... au cas où les essais ne marchent pas trop.
 
Pour le répertoire en question, il doit contenir un fichier de 250Go comme a dit BlockDevice. Je me rappelle de ça mais pas du chemin.