Reprise du message précédent :

Fallait pas installer Arch

Tu peux toujours essayer Gnome 3.2
Un dépôts à été créer à cet effet:
http://www.planet-libre.org/?post_id=10115

En tous cas, j'ai des update à coup de 100mo une à deux fois par semaine
 
J'ai http://ctkarch.org/ comme distribution : ça passe pas mal sur un vieux laptop DELL 1,2MHz.

 
Tain   j'imagine pas sur mon P3M 1.6GHz  

Je n'ai pas saisi l'ironie je pense

MegaHertz, GigaHertz toussa

Ah ok

j'avais pas fait de maj depuis des mois, j'ai flippé, j'ai tout backupé et lancé un pacman -Syu, et voila, je suis passé du kernel 2.6.38 à la dernière version avex 1.2 Go de dl.
Une recompil du module virtualbox plus tard, tout roule.
 
arch ca poutre le monde entier doit s'y mettre

Il manque quand même un truc essentiel à Arch, ce sont les paquets de debug.

 
 
skoi ca?

 
Paquets compilés avec des flags de debug.
 
Et je ne trouve pas, en general, si t'as envie de debugger un logiciel/ avoir tous les symboles de débugs, tu le compiles de ton cote (et via abs c'est pas trop dur)

j'ai rien compris mais merci    
 
 

http://gcc.gnu.org/onlinedocs/gcc/ [...] tions.html

Quand tu compiles un programme (C/C++ vers code machine), le compilateur applique plus ou moins d'optimisations pour améliorer les performances du programme ( exemple: x = 2 + 2 ; devient x = 4, tu evites de devoir faire le calcul a chaque execution comme ca).

Les mainteneurs de Arch compilent et distribuent les paquets optimisés, ce qui est bon pour les perfs, mais lorsque tu veux débugger ces programmes (via GDB par exemple), c'est pas bon car les optimisations compliquent beaucoup/ suppriment des informations qui peuvent etre utile pour comprendre et identifier les bugs.

Certaines distributions proposent donc aussi les paquets debugs si tu as besoin de ceux la.

 
 
dans pas mal de programmes et/ou de scripts, tu peux passer des options, notamment une option de debug, qui ne sert que quand ton programme plante.
bien souvent tu l'appelles en tapant nom_de_ta_commande --debug
 
quand tu ecris le code source de ton logiciel, tu peux mettre, entre chaque ligne de code " utile " une ligne de code qui provoquera l'affichage de données courantes quand l'option --debug sera invoquée.
tu peux par exemple faire dire a ton script/programme une tétrachiée d'info comme  

• la derniere fonction utilisée et son résultat
• la position courante lors de l'execution
• l'etat de certaines variables
• etc...

 
tu peux donc avoir un programme script tout simple :  
 

 
qui te renverra trois lignes :
 

 
tu peux alors inclure une fonction de debug dans ton code
 

 
 
de cette maniere, si tu executes ce script et que tu valides le debug, celui ci affichera
 

 
 
 
donc le debug, ca te permet de savoir/d'afficher exactement jusqu'ou ton code s'execute, où il plante, pourquoi il plante, etc etc...
 
bon, evidemment, mon code est super trivial ( je doute meme qu'il s'execute, vu l'etat d'alcoolémie dans lequel je l'ai tapé   ), mais c'est pour te donner une idée
 
 
 
edit : bob, je te proute
j'aurais pas du finir mon vin de paille   j'ai été trop lent pour répondre

Faut avoir une méga connexion quand même ! On habite pas tous en france et 1.2G dans certaisn pays c'est la misère à télécharger.
Enfin bref moi sous debian la même chose j'ose dire avec apt-pinning ....

 
 
 
c'est très clair, grand merci :-)

 
voila ce que j'ai lors de la séquence du boot
fail au chipset son (pourtant le son fonctionne )  
 
de plus j'ai un autre soucis, mon portable reboot dans la nuit apres l'avoir éteint  
que faire ?  

Un article sur Arch...
http://www.h-online.com/open/featu [...] 43717.html
 
Pas lu par contre.

Question : Je viens d'installer Arch (version 32 bits), via le netinstall.
 
J'ai que le strict minimum dessus : les packages Core, Xorg, Slim et XFCE.
 
Slim lancé via l'inittab.
 
Dans mon rc.conf, j'ai juste rajouté dbus dans la liste des demons au démarrage.
 
Des que je passe en init 5, la console devient inutilisable (elle ne répond aux entrées clavier qu'une fois sur 5).
 
Sous X tout fonctionne bien, aucun ralentissement.
 
J'ai l'impression qu'en mettant dbus en démarrage "pas en tache de fond" (donc avec dbus et pas @dbus), le souci est atténué.
 
Ca dit rien a personne ?

tu as quoi exactement en demon ?

Alors :
 
en demons:
 

 
en inittab :
 

 
Installation stock, j'ai rien tuné encore sur la machine.
 

En lançant slim par les démons et en repassant le initdefault à 3?

Arch c'est bien (je l'utilise à la maison), mais je pense que les distributions plus connues sont plus adaptées à une utilisation moderne d'un PC

 
Avec des arguments?  

-Syu

Voilà

clairement je voit pas bcp de distrib avec moins de maintenance qu'arch

https://wiki.archlinux.org/index.ph [...] tributions

Les différences sont bien expliquées ici, page détaillée et honnète

Clair qu'il faudrait un peu argumenter parceque brut de pomme comme ça, c'est un peu léger.

t'es encore sur vendredi la?
 
chez nous c'est passé à samedi, t'as peut etre du décalage horaire...
 

Blinkage :

D'ailleurs je gère les MAJ chez ma mère et un pote que j'ai converti (total néophyte) avec une install auto des MAJ (via KPackageKit), et depuis, je n'ai plus à entretenir sa machine... Ca change de l'époque où elle tournait sous XP.

Utilisation moderne=desktop=ergonomie tout ça, dont outils graphiques un minimum quoi, et puis les -Syu qui font qu'il faut tout changer dans sa configuration, ils pourraient faire plus simple, pour une distribution qui se veut stupide, après je dis pas qu'on s'éclate pas quand tout est réglé et paufiné, à part ça j'suis très content que ça existe une distribution comme celle-ci

Sans rentrer dans un grand débat qui a déjà eu lieu plusieurs fois, AMHA :
- les outils graphiques existent pour ce qui est de tout faire sans passer par la CLI, notamment avec PackageKit qui s'interface avec pacman et ses GUI associés (perso je tourne avec KPackageKit, c'est sans souci)
- les MAJ qui imposent des modifications de fichiers de conf sont relativement rares, et en tout cas pas plus nombreuses que celles qui peuvent potentiellement foutre la merde dans un autre OS si on considère qu'un Syu a une portée à l'échelle du système dans sa totalité (OS + logiciels installés) et pas uniquement sur le coeur de l'OS
- d'un point de vue néophyte, et cela recoupe un peu le point précédent, la maintenance induite par un Syu et qui requiert l'équivalent d'un retour chez l'assembleur ou l'appel à l'ami kissiconnait n'est pas plus importante qu'avec n'importe quel autre OS/distribution

Arch est une distrib qui donne beaucoup de clé à l'installateur de la machine et qui est du coup peut être à peine plus complexe que d'autres du fait qu'elle fait intervenir dans sa configuration de base des concepts évolués qui requièrent parfois des connaissances un peu plus pointues que pour une autre distrib, mais c'est l'équivalent du travail qui revient au professionnel ou au kissiconnait pour l'installation et la configuration de base de nlimporte quel OS. Pour le reste, Arch reste une des distributions les plus simples à maintenir, y compris de manière automatisé, et la comparaison tient toujours si on élargit la comparaison aux autres OS lorsqu'on les considère en tant qu'OS plus écosystème logiciels complet et complexe.

Toujours AMHA, bien entendu.

 
Ouais c'est rare le gros pétage   Il faut en fait suivre les news sur archlinux.org en page d'accueil.
C'est pareil sur toutes les distributions quand tu mets à jour. Après oui, c'est pas super user friendly, c'est clair. Mais comme je suis admin sys linux, je m'en fout    
 
Bon sinon, j'ai rejoué avec e4rat pour le préchargement de fichiers au démarrage.
J'ai fait une manip pour alléger un peu le startup.log, puis j'ai fait la réallocation. Voilà ce que j'ai fait au startup.log :  
cat startup.log| grep -v /home/ | grep -v /tmp | grep -v /proc | grep -v /sys | grep -v /dev > startup.log2
 
Sans déconner, j'ai la main sous kde en 30 secondes   Je vais chronométrer   J'ai même du revoir l'ordre de boot dans mon rc.conf, je comptais en général sur la lenteur du système pour que les services lancés en parallèles soient lancés avant kde (comme dbus, wicd), et là, et non  
 
edit : bon un peu optimiste, faut compter 1 minute de démarrage, tout chargé, connecté en wifi  

c'est pas un peu beaucoup une minute?
bon en meme temps on connait pas ta conf
d'ailleurs chez moi un des trucs qui bloque au boot (j'exagere, ca doit rester une grosse seconde dessus, mais vu que tout le reste passe assez vite pour que j'ai le temps de rien lire c'est pas top) et qui pourrait tres bien se faire en arriere plan c'est l'activation de la swap, y a pas une methode propre pour le faire en arriere plan? de toutes facons le temps que je tape mon mot de passe dans gdm il a le temps de faire sa sauce derriere.
bon, apres y a le post de la carte mere, c'est le truc le plus long que j'ai au boot et ca fait ch***.

Supprimer le swap ?

Il voulait un argument

KISS
Je préfères ça a une usine à gaz. Avec Arch, je maitrise mon OS, pas l’inverse.

 
Bah en fait, avec bootchart, le boot jusqu'à X passe en environ 17 secondes.  
Mais après, faut lancer X et kde, et c'est juste ultra long    
Je pense que ça va être difficile de faire mieux avec un disque dur 5400 rpm    

 
Bah là tu vois sur mon laptop, j'utilise une distribution qui fait partie de ce que tu considères comme usine à gaz : OpenSUSE, oui je sais microsoft distribution morte tout ça....  
Et c'est vrai ça doit rajouter 2 MB de trucs sur le bureau KDE quand c'est chargé et ça c'est vraiment mais vraiment pas Bien! Mais en pratique ça consomme pas plus que mon bureau KDE avec le minimum sous arch, en pratique aussi c'est rapide, réactif stable... Et les interfaces graphiques ça a son charme si c'est bien fait. Il me semple que Linus Torvalds, oui celui qu'on appelle le Troll, mais aussi celui qui a écrit les premières lignes du noyau, pense que c'est le travail de la distribution de faire les trucs en coulisse (configurations minimales, compilations), sinon autant faire la sienne "from scratch"  car il préfère fouetter d'autres chats que de se battre contre l'eau

 
Oui, mais l'intérêt de arch outre la légèreté, c'est clairement le côté technique : on peut comprendre comment ça marche en lisant le code, et on est toujours à jour. C'est pour ça que je l'utilise.  
Sur mon pc-taff, j'ai pas le temps de m'occuper de ces détails techniques, et dans ce cas, c'est ubuntu ou debian stable...
 
Bref, y'en a pour tout le monde, parce que Linux, c'est le bien

Je vois qu'on est bien daccord Y a une distrib pour toutes les utilisations, et des distribs qui conviennent à toutes les utilisations aussi