-=[ silmaril ]=- a écrit 1472 commentaires

Non les inodes sont les equivalents des cluster de la FAT/FAT32 ie c'est l'ensemble de secteurs le petit que gere le système de fichiers. Par ex avec des inodes a 4Ko tout fichiers de taille inferieur a 4Ko prendra la place d'un fichier de 4Ko pour le système (mais pas sur le disque).

le resultat que tu obtient pour la commande 'df -i' doit etre lié au système de fichier que tu utilise (ex chez moi j'ai la meme chose pour du reiserfs, je testerai plus tard sur XFS mais cela ne doit marcher correctement que sur ext2/ext3).

Sinon pour l'explication et bien je pencherai pour un rm tardif par firefox (si effectivement le fichier que tu a utilisé pour le resume viens bien de lui).

Et bien pour cela le LiveCD ou LiveNimporteQuoi n'est pas le plus adapté (ou alors je n'ai pas compris ce qui te gene dans ce livecd particulier). En passant le LiveCD sysrescuecd est en fait une gentoo.

1/ le noyau ne fait pas de detection de materiel, il se contente d'initialiser les drivers non compilés en modules. Les systèmes de detection de materiels sont exterieurs au noyau. Ie un driver peut etre charger et s'afficher comme tel sans qu'il n'y ai de materiel a gerer.

je verrai bien un truc dans le genre:
ttyS00 at 0x03f8 (irq = 4) is a 16550A
ttyS01 at 0x02f8 (irq = 3) is a 16550A
Real Time Clock Driver v1.10e

Mais sur un 2.4 (sans module) cela se passe avant le chargement des pilotes IDE et USB. je vais voir sur un 2.6 mais ca doit etre a peu pres pareil.

Autre question: le probleme arrive lors du chargement du CD d'install Suse ou apres l'installation ?

Et y a t'il les meme problèmes avec une distro x86 'normale' ? (et non compilée x86-64)

Le pb pour repondre a ton problème c'est que tu melange tout :(
SysLinux n'est qu'un bootloader pour linux (a l'instar de lilo et ou grub) qui permet le chargement depuis des disquettes, des CD ou un reseau. une fois le kernel charger il n'y a plus de syslinux.

Ce qu'il serait necessaire de savoir c'est:
1 quand il plante a t'il fini le chargement du kernel et est t'il passé au stade init. C'est a dire est-ce que la partition racine a pu etre mountée et le noyau a t'il passé la main a la distrib proprement dite ou cela se passe t'il toujours dans la phase d'initialisation du noyau.

2 Quelle est la ligne de texte exacte precedent le Kernel Panic

Note: l'agpgart est lié au chipset de la carte mere et plus specialement a cette partie du chipset qui controle le pont AGP. Donc jamais tu ne chargera un module matrox a ce momment la. Pour la partie DRI oui mais cela se fait de maniere quasi transparente par XFree.

netperf: http://www.netperf.org/netperf/NetperfPage.html?(...)

fournit avec les debian :)

et si tu utilisait un cdrecord recent qui sache graver en IDE ?

ACPI => Advanced Configuration & Power Interface
permet la configuration des peripheriques sur les differents bus compatibles
et la gestion de l'energie

APIC => Advenced Programmable Interrupt Controlleur
C'est un chip qui est apparu avec les premier bi-pro pour repondre au meme
probleme que l'IRQ-sharing mais d'une autre maniere: l'augmentation du nombre
de ligne IRQ (ligne d'interruptions materielles). La ou la deuxieme methode
necessite une detection logicielle de qui a reellement envoyer la requete d'interruption
cette solution permet de revenir a l'affirmation une IRQ = un Composant en augmentant
le nombre d'IRQ a 24.

Par contre il necessite une mise a jour du kernel pour supporter ce nouveau controleur

Moi j'ai commencé par une Redhat a l'époque ou elles etaients correctes (5.x) puis je suis passé sur plusieurs atres debian (toutes depuis la premiere potato) quelques redhat 8, quelques mandrake (la pire de toute pour moi) et la je teste depuis qques temps la gentoo, et je suis serieusement décu.

Je ne pensait pas avoir un gain important en perf au niveau appli donc ce n'est pas ca :) C'est plutot au niveau fonctionnement de trucs simples comme emerge par ex, tout le monde sait que compiler gcc bon c'est pas tres rapide (et c'est pas le plus long hein) il pourrai en profiter pour downloader les packages suivants pdt ce temps ce qui ne ralentirait pas la compilation ou si peu et pourrait donner un boost au processus global mais il le fait pas, il y a toutefois moyen de le faire a la main en lancer en parallele un emerge -f mais la garre ils n'ont pas penser a faire un verouillage (lock) sur le download des archives alors si les deux emerge se retourvent a dl en // le meme fichier ... BOOM.

Et meme la debian a un comportement plus adapté au connexion dialup, elle commence par faire le download et ensuite s'occupe du reste ce qui est plus logique bien que il pourrait etre possible la aussi de lancer l'install de packets au fur et a mesure.

Pour l'instant je reste sur la gentoo pour profiter du paquet entrance mais je crois que ca ne va pas durer (surtout qu'entrance est loin d'etre fini :-( ).

y a meme moyen de faire la meme chose avec emacs (en utilisant tramp). La syntaxe d'ouverture de fichier devient: <</[methode:]user@host:/path/to/file>>

on peut meme faire du multi host

2Go => 2048Mo
le tout en 9h donc ca nous fait du 227Mo/h
or il y a 60Minutes dans une heure donc ca nous fait du 3.79Mo/min
donc du 0.06321Mo/s
ou 64Ko/s donc tout va bien :)

Correction il y a deux methodes pour gerer les signaux en wxWindows, la premiere a base de macros (et comme je le dit plus haut certainement dérivée de la librairie Object Windows Librairie de Borland et des MFC) et la seconde plus proche du système de Gtk-- avec une methode Connect:
http://wxwidgets.org/hworld2.txt(...)

Par contre pas le choix pour le prefixe, effectivement ils ne semblent pas connaitre les namespaces (et pour les utiliser soit meme avec wxWindows il faut bidouiller apparement cf http://wiki.wxwidgets.org/wiki.pl?Namespaces(...)) Mais il est vrai que certaines compilateurs C++ les gerent tres mal c'est surement a cause de cela.

> Déjà rien que les premieres lignes de code me rebutte. Je deteste l'utilisation de Macro en C et encore plus en C++.
> L'héritage et la composition permette largement d'éviter d'utiliser ce type de rustine.

C'est marrant ca me rappelle la libraire OWL utilisée par Borland C++ jusqu'a la version 5 :) A l'epoque y avait pas trop le choix, mais c'est vrai que depuis je prefere le mecanisme de Gtk-- (celui de Qt c'est encore pire car il necessite un precompilateur pour gerer les signaux).

Pdt un mooment je me suis dit tiens pourquoi pas s'interesser a cette lib, mais finalement je sens que je vais rester sur CommonC++/Gtk--

Bein si tu as fait ce que je pense (copie du tube X0 ce qui est crade) tu aurais mieux fait de lancer le X avec un listen tcp et de changer ton display pour le chroot en 'localhost:0.0'

Bref, ce qui me fait mal au cul, c'est que d'une part Internet Explorer gère son cache très bien

Tres bien c'est vite dit, j'ai eu plus de problèmes de cache avec IE qu'avec tout les mozilla et Mozilla Phoenix,Firebird,Firefox que j'ai eu.
Notament des problèmes de sites que ne se rafraichissait plus et de
formulaires qu'il est incapable de retrouver en revenant en arrière alors...

C'est marrant mais j'ai toujours cru que le LVM venait d'un boite appellée Sistina et non IBM, comment peuvent t'il accuser IBM sur un truc qu'ils n'ont pas ecrit ?

Pourquoi ? Parce que :)
Non serieux, quand tu change un theme (et c'est vrai pour KDE ou pour Gnome hein faut pas deconner non plus, et kde avec sont processus en plus pour chaque appli il me fait bien rire mais bon), donc quand tu change un theme il faut changer:
1 l'apparence du gestionnaire de fenetre (metacity ou saw{fish|mill}) ie les bordures et autres decorations (ca ca marche apparement)
2 la presentation des differentes sous parties de gnome (le panel, le bureau, les icones ...) (ca aussi apparement).
3 la methode utilise par GTK pour afficher l'interieur des fenetres Gnome/Gtk. C'est ce qu'on appelle 'moteur de rendu' ou 'drawing engines'. Et la ca coince c'est donc que le ou les moteur necessaires a tes themes Gnome ne sont pas disponibles sur ta machine (sur debian/gentoo ce sont des packets nommés gtk-engines-quelquechose. Verifie s'il y en a d'installé sur ta machines et si oui verifie si ton theme n'en necessite pas un special.

Note 1: Un moteur de rendu gtk peut etre configurable et etre utilise sur plusieurs theme differents
Note 2: Si j'ai tout explique c'est a cause du 'debutant', ca peut toujours servir.

Les seuls truc qui seront pas impactés c'est les programmes ecris directement en assembleur ... moins intuitif l'assembleur ... mais compatibilité direct.

Au contraire ca risque d'etre les plus impactés, autant un compilateur C +/- intelligent pour transformer automatiquement le stockage ou presenter un warning, autant un prog assembleur ecrit pour i386 ne pourra jamais profiter aussi simplement du 64bit, du MMX et autre 3dnow.
Tu te plaind de ceux qui n'utilisent pas sizeof, et tu prefere l'assembleur .... C'est que tu n'a jamais du coder un soft entier en assembleur.

Non ce qu'il veut dire c'est que ce sera principalement le noyau et les operations memoire qui y sont associées qui profiteront le plus du 64 bits.
D'ailleurs les doc du portage Debian sur Sparc 64bits indiquent que seul le noyau a vraiment besoin d'etre compilé pour 64bits le reste du système ne profitant pas d'un gain important par rapport a la perte de place.

PS: et arretez de sortir gentoo a tord et a travers. La debian est depuis bien plus longtemp portée sur de multiples architectures (au moins 10) et c'est d'ailleurs la raison principale des temps importants d'integration des paquets qui necessitent une validation sur tout les ports avant d'etre intégré en stable/testing.

Tu auras bcp moins de soucis avec un vrai fs journalisé qu'avec ext3 (qui peut gérér la journalisation des data mais depuis le gros bug annoncé la dessus personne n'en a annoncé la correction). Perso je mettrait du XFS ET du ReiserFS selon l'usage des partitions (voir de l'ext3 en plus mais bon j'aime pas ce n'est qu'une grosse rustine sur l'extended 2 et les soucis avec sont monnaie courante).

Pour savoir quel fs/quel usage il suffit d'une petite recherche sur les performances comparatives des fs journalisés.

Oui si tu faisait ce qu'il demande peut etre que cela marcherait :)


configure: error: SVG requires a modified version of libart. To pull and build this LGPL library,
* set MOZ_INTERNAL_LIBART_LGPL, and <== ca c'est bon
* then rerun the checkout stage <== ca tu ne l'as pas fait.

il faut donc que tu te refere a la page suivante:
http://www.mozilla.org/cvs.html#sandbox(...)
pour transformer ton archive en repository CVS et inserer la libraire libart dans le repository

Il va te falloir un ecran et un clavier pour la premiere phase de l'install (jusqu'a ce qu'il ai un moyen de continuer sans, soit un telnetd soit un sshd)

Ca se fait tres bien ave LVM + XFS (en augmentation toutefois). C'est faisable aussi avec une partition 'normale' mais il faut que le kernel ai pris en compte la nouvelle table de partition (ie soit qu'il n'y ai rien d'utilisé sur le disque -- swap y compris --, soit apres un reboot).

Nan c'set parce que ils ne fonts que les distribuer (Comme bcp d'autres d'ailleurs).

et galeon :)

Juste que les drivers du nforce sont plutot recent, pas forcement au point, et que IIRC les Nforce et les carte graphiques non Nvidia ca marche pas tip top (un pb avc l'agpgart, peut etre resolu depuis. Mais pas forcement dans toutes les distros).