Pour obtenir la liste de tous les protocoles disponibles sous KDE, il est possible d'aller voir l'aide, en passant par le protocole "help" : dans la barre d'URL de konqueror, ou l'exécution rapide, taper "help:kioslave".
Tout à fait. C'est dans des circonstances exceptionnelles, dans lequelles on juge habituellement que la machine est inutilisable, qu'on est en train de faire des progrès.
Et pour l'utilisateur moyen qui n'en retire pas de bénéfice direct (à part de pouvoir se vanter d'utiliser un OS allant 100 fois plus vite qu'hier, ce qui ne veut rien dire), on en retirera de bonnes choses. Je pense par exemple aux serveurs d'applications J2EE et aux BD, ces gros monstres qui utilisent énormément de threads et de mémoire... Ils tourneront probablement bien mieux. Et donc les entreprises continueront à aider les développements autour de "Linux", ce qui aura sûrement un impact positif même sur nos applis de tous les jours.
Donc ce sont de bonnes nouvelles.
Tu peux toujours utiliser des pointeurs de fonctions en C++ si tu veux.
L'avantage du C++, c'est que c'est (quasiment) un sur-ensemble du C. Il fournit (presque) tout ce que permet le C, et bien plus encore, tout en générant un code aussi optimisé, si le compilo est correct.
Programmer les templates en C avec des macros, j'ai déjà donné. Je crois que je ne referai plus jamais ça.
La différence est qu'en C++ tu le fais avec des conteneurs (templates), alors qu'avec la glib tu fais ça avec des pointeurs sur fonction. En pratique, le code généré en C fait des indirections à gogo, alors que dans le C++ tout peut être optimisé à fond.
Je ne suis pas tout à fait d'accord avec la comparaison... On condamnerait un marchand d'armes s'il vendait ses armes à des particuliers, sans respecter les lois de distribution des armes.
Par contre, je suis plutôt d'accord sur la comparaison avec les extincteurs...
Les outils de P2P sont un moyen de distribution de d'information très efficace. C'est l'usage qui en est fait qui n'est pas très légal.
La grande question est de savoir si quelqu'un fait du business avec les oeuvres piratées. C'est ceux là qui devraient aller en taule.
"le nombre de périodes de temps CPU indivisibles" par seconde (normal pour des HZ)... Donc plus il y en a par seconde plus elles sont courtes. C'est chaque période qui est indivisible. Il me semblait que le nom HZ était suffisamment parlant pour me comprendre... Désolé.
Relis bien...
Si tu prends la main plus vite, c'est qu'on te l'a donné plus vite. On dit donc la même chose. J'avoue que mon explication n'a pas été très claire. Mais elle est correcte.
C'est le nombre de périodes de temps CPU indivisibles accordées aux processus gourmands en CPU. Plus HZ est grand, plus le système est réactif car tu donnes plus vite la main à un autre processus qui a besoin du CPU.
"Je crois qu'il est peut-etre mieux de developper des systemes de fichiers virtuels ou l'on peut naviguer dans les archives."
Le Hurd le permet déjà grâce au mécanisme des translators. N'importe quel utilisateur peut ajouter un translator en tout point du système de fichier sur lequel il a un droit d'écriture. Ce translator est un programme qui se comporte comme un système de fichiers, qui tourne avec les droits de son propriétaire. Ca permet de "monter" un répertoire ftp distant par exemple. Théoriquement, ça peux permettre aussi de parcourir des archives
".tar.gz" comme si elles étaient déjà décompressées.
Ce serait super cool si Linux avait ça aussi. Je me demande si je ne travaillerai pas sur ce projet un jour...
Pour les sauvegardes, outre un système de backup dont je dispose au travail, il existe deux outils très utiles. Le très connu rsync, mais aussi unison http://www.cis.upenn.edu/~bcpierce/unison(...) . J'utilise quotidiennement unison pour synchroniser mon compte entre plusieurs machines : un PC chez moi, un portable, mon PC de bureau, et un serveur de projet. Ca me permet de travail sur n'importe quelle machine de mon choix, et de répercuter les modifs sur les autres machines. Evidemment, il faut régler à la main les conflits sur les fichiers modifiés sur les deux machines depuis la dernière synchronisation. Je ne sais pas où on est dans le domaine des systèmes de fichiers sur CD, mais si on avait un système de fichiers RW sur CDR ou CDRW, on pourrait utiliser unison et rsync très efficacement. Pour le multicd, c'est une autre histoire.
Tout dépend du soft. Il faut utiliser un profiler pour voir où il passe son temps. Si c'est dans la glibc, il vaut mieux qu'elle soit optimisée. Mais en général, le temps est perdu principalement dans les E/S et dans le code de l'application, rarement dans la glibc. Donc ce n'est pas toujours crucial qu'elle soit optimisée.
Il faut taper sur E pour éditer les lignes de commandes de noyau, et là tu peux changer les paramètres à passer au noyau, et donc lui ajouter le paramètre "single".
Quand tu as fini d'éditer, ESC puis B pour booter.
Ca ne change pas les paramètres de boot de manière permanente, c'est seulement pour ce boot là.
Je crois qu'on est nombreux à attendre ton DivX maintenant ! Au fait, quelqu'un sait-il enregistrer en haute résolution à partir d'une carte tuner TV ? Quels outils utilisés vous ? Je penche pour une solution d'enregistrement avec encodage mpeg à la volée puis recompression DivX derrière, mais je n'arrive pas à faire marcher l'encodeur de mplayer avec ma carte TV (il échange le bleu et le rouge dans l'image !).
Il prend peut-être beaucoup d'espace mémoire, mais cet espace mémoire est généralement de l'espace PCI. Par exemple, une partie de la RAM de la carte vidéo est comptée là dedans. Ainsi que l'espace utilisé par tous les registres d'accès à la carte. Ca ne veut pas dire que c'est de la RAM de la carte mère qui est consommée.
L'idée semble intéressante. Il faut trouver des gens qui puissent s'impliquer dans de tels projets.
Mais je souhaite que cet effort de traduction complet du KT continue. Ca m'intéresse beaucoup. Il faudrait pouvoir obtenir des stats d'accès à la traduction déjà faite pour voir si l'effort en vaut la peine. Mais il faut aussi qu'avant la pub ait été faite sur tous les sites de news Linux francophones. Il faudrait peut-être aussi demander à Zack Brown de faire de la pub pour toutes les traductions qui ont été faites récemment... Les francophones directement concernés qui ne lisent pas Linuxfr verraient alors l'info.
La question est bien là : les techniciens du noyau savent déjà lire l'Anglais... Je fais partie de ceux qui touchent au noyau, et ça fait longtemps que je lis ces condensés... en Anglais. Néanmoins, si la version Française sortait aussi le lundi ou peut-être un ou deux jours plus tard, je crois que je la préfèrerais largement à la version en Anglais. C'est quand même bien plus reposant et rapide de lire du Français que de l'Anglais.
S'il y a trop de de délai, ça ne me servira pas beaucoup.
D'où ma question : quel peut-être le délai de traduction ? Plus il sera court, plus le public sera intéressé !
En attendant, félicitations pour cette page, je l'ai déjà lue, mais je la relirai avec plaisir en Français.
Alors à mon avis, tu ne connais pas encore tout de l'informatique.
Sous Unix, une grande partie des données stockées non compressées le sont souvent en formant texte, lisible par l'humain. C'est le cas de tous les fichiers de config, des pages web (ça, c'est valable partout), les entrées de /proc et aussi des répertoires de mail. Donc les nombres sont souvent écrits en décimal. Il est donc possible qu'on ait des problèmes avec des puissances de 10 et non des puissances de 2.
# Liste de tous les protocoles
Posté par Simon_N . En réponse au message [X-Window] Pages de man sous KDE. Évalué à 1.
[^] # Re: Ben dis donc !
Posté par Simon_N . En réponse à la dépêche Gestion de la mémoire virtuelle du noyau 2.5.x. Évalué à 10.
Et pour l'utilisateur moyen qui n'en retire pas de bénéfice direct (à part de pouvoir se vanter d'utiliser un OS allant 100 fois plus vite qu'hier, ce qui ne veut rien dire), on en retirera de bonnes choses. Je pense par exemple aux serveurs d'applications J2EE et aux BD, ces gros monstres qui utilisent énormément de threads et de mémoire... Ils tourneront probablement bien mieux. Et donc les entreprises continueront à aider les développements autour de "Linux", ce qui aura sûrement un impact positif même sur nos applis de tous les jours.
Donc ce sont de bonnes nouvelles.
[^] # Re: c++ su><or
Posté par Simon_N . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.
void toto(void *(*f)(void *))
{
f(0);
}
char *titi(char *x)
{
cout << "OK" << endl;
return 0;
}
int main()
{
toto((void *(*)(void *))titi);
}
[^] # Re: c++ su><or
Posté par Simon_N . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 2.
L'avantage du C++, c'est que c'est (quasiment) un sur-ensemble du C. Il fournit (presque) tout ce que permet le C, et bien plus encore, tout en générant un code aussi optimisé, si le compilo est correct.
Programmer les templates en C avec des macros, j'ai déjà donné. Je crois que je ne referai plus jamais ça.
[^] # Re: c++ su><or
Posté par Simon_N . En réponse à la dépêche Interview de Bjarne Stroustrup. Évalué à 10.
[^] # Re: Normal
Posté par Simon_N . En réponse à la dépêche KaZaa : industrie vs musique. Évalué à 10.
Par contre, je suis plutôt d'accord sur la comparaison avec les extincteurs...
Les outils de P2P sont un moyen de distribution de d'information très efficace. C'est l'usage qui en est fait qui n'est pas très légal.
La grande question est de savoir si quelqu'un fait du business avec les oeuvres piratées. C'est ceux là qui devraient aller en taule.
[^] # Re: Comment ?
Posté par Simon_N . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à -1.
[^] # Re: Comment ?
Posté par Simon_N . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à 0.
Si tu prends la main plus vite, c'est qu'on te l'a donné plus vite. On dit donc la même chose. J'avoue que mon explication n'a pas été très claire. Mais elle est correcte.
[^] # Re: Comment ?
Posté par Simon_N . En réponse à la dépêche Entrevue avec Daniel Robbins de Gentoo. Évalué à 10.
# rdate
Posté par Simon_N . En réponse au message [Terminal] Mettez-vous à l'heure. Évalué à 1.
[^] # Les translators du Hurd
Posté par Simon_N . En réponse à la dépêche Archives auto-extractibles. Évalué à 6.
Le Hurd le permet déjà grâce au mécanisme des translators. N'importe quel utilisateur peut ajouter un translator en tout point du système de fichier sur lequel il a un droit d'écriture. Ce translator est un programme qui se comporte comme un système de fichiers, qui tourne avec les droits de son propriétaire. Ca permet de "monter" un répertoire ftp distant par exemple. Théoriquement, ça peux permettre aussi de parcourir des archives
".tar.gz" comme si elles étaient déjà décompressées.
Ce serait super cool si Linux avait ça aussi. Je me demande si je ne travaillerai pas sur ce projet un jour...
# Sauvegardes par synchronisation de copies
Posté par Simon_N . En réponse à la dépêche Sauvegardes pas chères.... Évalué à 10.
[^] # Re: ca va plus vite ?
Posté par Simon_N . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 6.
[^] # Re: ca va plus vite ?
Posté par Simon_N . En réponse à la dépêche Une distribution à compiler soi-même. Évalué à 10.
[^] # Re: LILO avec une image
Posté par Simon_N . En réponse à la dépêche LILO bouge encore !. Évalué à 10.
Quand tu as fini d'éditer, ESC puis B pour booter.
Ca ne change pas les paramètres de boot de manière permanente, c'est seulement pour ce boot là.
[^] # Re: Rediffusion
Posté par Simon_N . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 1.
[^] # Re: Rediffusion
Posté par Simon_N . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 3.
[^] # Rediffusion
Posté par Simon_N . En réponse à la dépêche Emission sur Echelon a la television. Évalué à 8.
[^] # Re: Désagrément ...
Posté par Simon_N . En réponse à la dépêche Nouveaux drivers Nvidia. Évalué à 1.
[^] # Re: Disponibilité des traductions
Posté par Simon_N . En réponse à la dépêche Traduction en francais de kernel traffic #139. Évalué à 3.
Mais je souhaite que cet effort de traduction complet du KT continue. Ca m'intéresse beaucoup. Il faudrait pouvoir obtenir des stats d'accès à la traduction déjà faite pour voir si l'effort en vaut la peine. Mais il faut aussi qu'avant la pub ait été faite sur tous les sites de news Linux francophones. Il faudrait peut-être aussi demander à Zack Brown de faire de la pub pour toutes les traductions qui ont été faites récemment... Les francophones directement concernés qui ne lisent pas Linuxfr verraient alors l'info.
[^] # Re: Disponibilité des traductions
Posté par Simon_N . En réponse à la dépêche Traduction en francais de kernel traffic #139. Évalué à 10.
S'il y a trop de de délai, ça ne me servira pas beaucoup.
D'où ma question : quel peut-être le délai de traduction ? Plus il sera court, plus le public sera intéressé !
En attendant, félicitations pour cette page, je l'ai déjà lue, mais je la relirai avec plaisir en Français.
[^] # Re: Sérieux !
Posté par Simon_N . En réponse à la dépêche Bug dans KMail: mettez à jour !. Évalué à 1.
Sous Unix, une grande partie des données stockées non compressées le sont souvent en formant texte, lisible par l'humain. C'est le cas de tous les fichiers de config, des pages web (ça, c'est valable partout), les entrées de /proc et aussi des répertoires de mail. Donc les nombres sont souvent écrits en décimal. Il est donc possible qu'on ait des problèmes avec des puissances de 10 et non des puissances de 2.