Normalement, il convient d'installer les sources de ton noyau dans /usr/src/linux-2.6.35.4 et non dans /usr/src/linux.
Tu peux remplacer make dep
make clean
make bzImage
make modules
simplement par make
D'autre part make headers_install ARCH=x86_64 INSTALL_HDR_PATH=/usr/include
est une mauvaise idée car tu écrases les headers fournit par la slack (package kernel-headers). Ce qui est dans /usr/include/linux ne devrait pas être modifié tout seul car ces headers ont servi pour la compilation de la glibc et font donc partie de la chaine de compilation.
Est-ce indispensable pour toi de tourner avec un noyau 2.6.35.x ?
Sinon, je te conseille de réinstaller kernel-headers, kernel-source et de booter sur le noyau par défaut de la slack (le 2.6.33.4). C'est peut-être un manque de cohérence dans les versions de noyau qui te causent des soucis.
POV-Ray (ou autre logiciel de lancer de rayon) peut faire de très bonnes choses en optique même si son utilisation reste souvent plus généraliste.
Fais une recherche Google (pov-ray+optical+design), tu devrais trouver des liens intéressants.
Je ne peux que plussoire. Je ne voudrais pas que l'on pense que les moules sont des fainéantes qui ne passent leur temps qu'à écrire des commentaires inutiles qui n'amènent rien de nouveau ou d'intéressant aux articles.
Alors, encore bravo axel, et voici donc un comm, comme disent les jeunes d'aujourd'hui, afin de soutenir cette grande famille du bouchot et de montrer qu'elle est capable de participer de manière constructive et argumentée à des news de qualité.
Si OpenSSH s'est imposé, c'est surtout du fait de sa qualité. Les p'tits gars d'OpenBSD s'y connaissent en sécurité, et c'est ce qui fait toute la différence sur leur implémentation du protocole.
L'option --quoting-style est spécifique au ls des GNU Coreutils. Elle ne fonctionne pas avec le ls des BSD* par exemple. Donc cette solution n'est pas portable.
Oui, c'est super SuSE Studio, mais le principe n'est vraiment pas nouveau.
NimbleX propose une chose similaire depuis plusieurs années. Elle est basée sur Slackware et l'on peut créer son Live-CD, en ligne, via une interface ajax.
Il faudrait aussi revenir sur toutes les manières de créer un mot
Le français est une langue d'usage. Des mots sont créés par les locuteurs, ils vivent ou meurent. Ceux qui survivent et sont largement employés et compris par les francophones finissent un jour dans le dictionnaire. La norme est faite sur l'usage.
Le fait que la langue soit normée depuis cinq siècles
Cinq siècles ? Depuis l’ordonnance de Villers-Cotterêts ? Cette ordonnance imposa l'utilisation du français pour la vie publique (administration, justice ...) à la place du latin. Il n'était donc plus nécessaire d'être particulièrement érudit pour comprendre les textes de loi. Il a bien fallu normaliser le français vernaculaire pour que tout le monde puisse se comprendre exactement.
Normée depuis cinq siècles laisse une impression de gravure dans le marbre. La norme a très souvent changé pour, justement, s'adapter à l'usage. Et c'est ce que fait l'Académie Française.
Maintenant, et à mon avis, le problème se situe surtout au niveau politique où les décisions sont plus idéologiques que pratiques. Les commissions gouvernementales ne font pas toujours un travail éclairé.
Le langage SMS ? On en reparlera dans 10 ans, pour voir ce qu'il en reste.
>Plus sérieusement, avant de lancer ce genre de trolls, il serait peut-être opportun de faire une comparaison et un récapitulatif avantages/inconvénients de ces deux shells (ou a défaut un lien vers un tel comparatif).
Où l'on voit que c'est le PowerShell de MS Windows qui a le plus de fonctionnalités \o/
Le shell est un composant critique sur un système, notamment du point de vue de la sécurité. L'ajout de fonctions dans tous les sens et d'extensions propres incompatibles avec les autres interpréteurs de commande augmente la possibilité de bugs et de failles.
Imaginez une faille de sécurité dans bash, sachant que presque toutes les distributions Linux l'intègre par défaut...
La course à l'ajout de fonctionnalités n'est pas forcément une bonne chose. Si l'on veut faire des choses compliquées avec le shell, et bien on appelle sed, awk, perl, etc.
Bref, est-ce vraiment un progrès que bash, zsh, cash, trollsh fasse même le café ?
Je viens de construire le diff entre Bind 9.4.2 et Bind 9.4.2-P1 pour voir à quoi ça ressemble. J'ai ignoré une partie de la doc qui gonflait astronomiquement le patch :
Si vous voulez tester rapidement OpenBSD sans vous embêter à partitionner votre disque, voici quelques explications pour le faire avec KVM :
1) Installer kvm sur votre distribution si ce n'est pas déjà fait (et vérifiez que vous avez bien le pilote kvm dans le kernel : $ zcat /proc/config.gz | grep KVM ) : http://kvm.qumranet.com/kvmwiki
2) Créer un fichier pour l'image disque (2Go est un minimum, il vaudrait mieux mettre 5Go ou 10Go si vous avez la place pour tester les packages/ports) :
$ qemu-img create OBSD 5G
4) Booter l'ISO en utilisant l'image disque :
$ qemu -hda OBSD -cdrom install44.iso -boot d -net nic,model=ne2k_pci -net user
- qemu s'appelle peut-être qemu-system-$ARCH sur votre système
- les options -net permettent de changer la carte réseau émulée par qemu car celle par défaut plantouille sous OpenBSD.
urandom est non bloquant mais il est lent et utilise (et réutilise) l'entropie du système. Ça peut être ennuyeux de se retrouver à court d'entropie pour d'autres applications.
L'auteur du patch écrit : It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.
En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom : http://billauer.co.il/frandom.html
Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.
Moi je n'ai pas Nautilus d'installé sur mon système et lister tous les fichiers de /usr/bin avec le sélecteur de fichier GTK met effectivement 3 plombes.
l'inconstance des API et ABI n'est pas un problème dans le monde du libre
Je crois que tu sous-estimes légèrement la difficulté de la tache. Il y a de plus en plus de projets libres qui n'arrivent plus à suivre le rythme de développement du noyau.
Juste un exemple : le projet grsecurity, qui essaie de renforcer la sécurité du noyau, vient de jeter l'éponge : trop de travail. Ils vont se rabattre sur le noyau LTS d'Ubuntu. Tant pis pour les autres. http://grsecurity.net/pipermail/grsecurity/2008-May/000927.h(...)
Ce n'est pas un problème libre/propriétaire, car au final, NVIDIA sort bien un nouveau driver régulièrement ; mais force est de constater, que sans l'appui financier d'une entreprise, il deviendra de plus en plus difficile de contribuer sérieusement au noyau. Je ne parle pas de coder des nouvelles choses, mais bien de maintenir son code.
Le diff entre Linux 2.6.20 et 2.6.25 fait 143Mo (19 319 patches), ce qui fait une moyenne (je ne l'ai pas inventé :-) de 42 patches par jour, ça donne de quoi s'occuper...
# Une solution possible...
Posté par Jérôme Pinot (site web personnel) . En réponse au message tar et md5. Évalué à 5.
$ tar tf plop.tar.gzplop/
plop/truc
plop/truc.md5
$ tar xzf plop.tar.gz plop/truc -O | md5sum | grep -q `tar xzf plop.tar.gz plop/truc.md5 -O|cut -d" " -f1` && echo OK || echo FAIL
Ça sort OK si le md5 correspond, FAIL sinon.
# Remarques
Posté par Jérôme Pinot (site web personnel) . En réponse au message Compilation kernel-headers avec kernel-source pour VMWare entre autre. Évalué à 4.
Tu peux remplacer
make dep
make clean
make bzImage
make modules
simplement par
make
D'autre part
make headers_install ARCH=x86_64 INSTALL_HDR_PATH=/usr/include
est une mauvaise idée car tu écrases les headers fournit par la slack (package kernel-headers). Ce qui est dans /usr/include/linux ne devrait pas être modifié tout seul car ces headers ont servi pour la compilation de la glibc et font donc partie de la chaine de compilation.
Est-ce indispensable pour toi de tourner avec un noyau 2.6.35.x ?
Sinon, je te conseille de réinstaller kernel-headers, kernel-source et de booter sur le noyau par défaut de la slack (le 2.6.33.4). C'est peut-être un manque de cohérence dans les versions de noyau qui te causent des soucis.
# POV-Ray ?
Posté par Jérôme Pinot (site web personnel) . En réponse au message optique géométrique - étude de diaphragme. Évalué à 2.
Fais une recherche Google (pov-ray+optical+design), tu devrais trouver des liens intéressants.
# Je m'y colle
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche NuTyX, une distribution francophone maintenue par des francophones pour les francophones. Évalué à 10.
[^] # Re: Je lâche un comm
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Panaché de brèves informatiques de la semaine. Évalué à 4.
Alors, encore bravo axel, et voici donc un comm, comme disent les jeunes d'aujourd'hui, afin de soutenir cette grande famille du bouchot et de montrer qu'elle est capable de participer de manière constructive et argumentée à des news de qualité.
# Enfin !
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Nouvelle version de LinuxFr.org. Évalué à 2.
Finies les pages web de grand papa ! Il ne manque plus que les smileys animés, j'espère que ça sera vite corrigé...
[^] # Re: Option max_lopp
Posté par Jérôme Pinot (site web personnel) . En réponse au message Problème de "loop" libre. Évalué à 2.
Vérifie que tu as bien les devices de créés dans /dev, peut-être que ton udev ne les a pas mis à jour.
Sinon, à la mimine pour tester :
# cd /dev# mknod loop8 b 7 8
et essaie ensuite de monter un CD en loopback sur /dev/loop8 pour voir...
[^] # Re: FreeBSD & NetBSD
Posté par Jérôme Pinot (site web personnel) . En réponse au message Detection du nombre de processeurs (cores). Évalué à 2.
[^] # Re: Prise de Notes
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Tomboy vs Gnote. Évalué à 5.
[^] # Re: Craintes
Posté par Jérôme Pinot (site web personnel) . En réponse au journal La mort d'un troll : GCC supportera les plugins. Évalué à 5.
Si OpenSSH s'est imposé, c'est surtout du fait de sa qualité. Les p'tits gars d'OpenBSD s'y connaissent en sécurité, et c'est ce qui fait toute la différence sur leur implémentation du protocole.
# Pour info
Posté par Jérôme Pinot (site web personnel) . En réponse au message Corruption de système de fichier ext3 sur RAID5. Évalué à 1.
http://lwn.net/Articles/349970/
[^] # Re: C'est du poulet !
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Une alternative à make(1). Évalué à 1.
L'option --quoting-style est spécifique au ls des GNU Coreutils. Elle ne fonctionne pas avec le ls des BSD* par exemple. Donc cette solution n'est pas portable.
# Et pendant ce temps, à Vera Cruz...
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Dans lequel on aborde la question du Tibet. Évalué à 4.
Il n'y a pas que le Tibet en Chine.
http://www.boston.com/bigpicture/2009/07/ethnic_clashes_in_u(...)
# PyMecavideo
Posté par Jérôme Pinot (site web personnel) . En réponse au message Acquisition vidéo et extraction d'infos: position, vitesse, acclération. Évalué à 6.
http://outilsphysiques.tuxfamily.org/pmwiki.php/Oppl/Pymecav(...)
http://linuxfr.org/2008/12/01/24748.html
# C'est pas nouveau
Posté par Jérôme Pinot (site web personnel) . En réponse au journal suse studio: ça troue le cul. Évalué à 10.
NimbleX propose une chose similaire depuis plusieurs années. Elle est basée sur Slackware et l'on peut créer son Live-CD, en ligne, via une interface ajax.
Wikipedia : http://en.wikipedia.org/wiki/NimbleX
Pour tester : http://custom.nimblex.net/
# Français, langue d'usage
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Les vierges effarouchées du langage. Évalué à 3.
Le français est une langue d'usage. Des mots sont créés par les locuteurs, ils vivent ou meurent. Ceux qui survivent et sont largement employés et compris par les francophones finissent un jour dans le dictionnaire. La norme est faite sur l'usage.
Le fait que la langue soit normée depuis cinq siècles
Cinq siècles ? Depuis l’ordonnance de Villers-Cotterêts ? Cette ordonnance imposa l'utilisation du français pour la vie publique (administration, justice ...) à la place du latin. Il n'était donc plus nécessaire d'être particulièrement érudit pour comprendre les textes de loi. Il a bien fallu normaliser le français vernaculaire pour que tout le monde puisse se comprendre exactement.
Normée depuis cinq siècles laisse une impression de gravure dans le marbre. La norme a très souvent changé pour, justement, s'adapter à l'usage. Et c'est ce que fait l'Académie Française.
Maintenant, et à mon avis, le problème se situe surtout au niveau politique où les décisions sont plus idéologiques que pratiques. Les commissions gouvernementales ne font pas toujours un travail éclairé.
Le langage SMS ? On en reparlera dans 10 ans, pour voir ce qu'il en reste.
[^] # Re: ROhhhhhhh
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie de GNU Bash 4.0. Évalué à 10.
http://en.wikipedia.org/wiki/Comparison_of_computer_shells
Où l'on voit que c'est le PowerShell de MS Windows qui a le plus de fonctionnalités \o/
Le shell est un composant critique sur un système, notamment du point de vue de la sécurité. L'ajout de fonctions dans tous les sens et d'extensions propres incompatibles avec les autres interpréteurs de commande augmente la possibilité de bugs et de failles.
Imaginez une faille de sécurité dans bash, sachant que presque toutes les distributions Linux l'intègre par défaut...
La course à l'ajout de fonctionnalités n'est pas forcément une bonne chose. Si l'on veut faire des choses compliquées avec le shell, et bien on appelle sed, awk, perl, etc.
Bref, est-ce vraiment un progrès que bash, zsh, cash, trollsh fasse même le café ?
[^] # Re: Voir les corrections des failles ?
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Faille sérieuse dans le protocole DNS. Évalué à 5.
http://ngc891.blogdns.net/pub/projects/patches/bind-9.4.2.pa(...)
http://ngc891.blogdns.net/pub/projects/patches/bind-9.4.2.pa(...) (version en couleurs)
Ce n'est, de toute évidence, pas un patch trivial. On dira également merci au ARC4 d'OpenBSD.
# Pour tester rapidement
Posté par Jérôme Pinot (site web personnel) . En réponse au journal OpenBSD 4.4 entre en Beta. Évalué à 10.
1) Installer kvm sur votre distribution si ce n'est pas déjà fait (et vérifiez que vous avez bien le pilote kvm dans le kernel : $ zcat /proc/config.gz | grep KVM ) :
http://kvm.qumranet.com/kvmwiki
2) Créer un fichier pour l'image disque (2Go est un minimum, il vaudrait mieux mettre 5Go ou 10Go si vous avez la place pour tester les packages/ports) :
$ qemu-img create OBSD 5G
3) Téléchargez l'ISO de développement (remplacer i386 par amd64 ou macppc, etc) :
$ wget ftp://ftp.eu.openbsd.org/pub/OpenBSD/snapshots/i386/install4(...)
4) Booter l'ISO en utilisant l'image disque :
$ qemu -hda OBSD -cdrom install44.iso -boot d -net nic,model=ne2k_pci -net user
- qemu s'appelle peut-être qemu-system-$ARCH sur votre système
- les options -net permettent de changer la carte réseau émulée par qemu car celle par défaut plantouille sous OpenBSD.
5) Suivre les instructions données ici :
http://openbsd.org/faq/fr/faq4.html#Install
- utilisez tout le disque
- paramétrez le réseau en dhcp
- média d'installation : cd
- après avoir lancé la commande halt, fermez qemu.
6) Après installation, démarrez le système via :
$ qemu OBSD -net nic,model=ne2k_pci -net user
Lire la page de man de qemu, de nombreuses choses sont paramétrables.
[^] # Re: coin
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie d'aMule 2.2.1. Évalué à 2.
[^] # Re: Pas d'entropie en trop
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie d'aMule 2.2.1. Évalué à 5.
L'auteur du patch écrit :
It seems the random number generator of libcrypto++ reads lots of bytes from /dev/urandom. I can't say that I understand how the donkey protocol works, but I doubt that's there any need for real strong encryption, and so rand() should do fine for random numbers.
En fait, urandom n'est même pas fait pour le chiffrement fort (voir la page de man). L'efficacité de /dev/random (en quantité) et /dev/urandom (en qualité) est toute relative. Le projet HLFS (Hardened Linux From Scratch) utilise d'ailleurs frandom et erandom :
http://billauer.co.il/frandom.html
Est-ce que le changement baisse la sécurité ?
X917RNG est de bonne qualité couplé avec du Triple DES. Malheureusement, le problème provient toujours de l'initialisation de l'algorithme. Si on n'utilise pas de source entropique, il peut être possible de prévoir la valeur du seed et donc de casser tout le système.
C'est ce qui s'est passé avec Netscape que David Wagner a cassé en 1995 :
http://www.cs.berkeley.edu/~daw/my-posts/netscape-cracked-0
Ici, il semble que AutoSeededX917RNG construit un seed à partir de rand(), qui n'est pas vraiment imprévisible...
Bref, l'entropie, c'est bon, mais je crois que décidément, ça ne plait pas aux debianistes.
# Pas d'entropie en trop
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Sortie d'aMule 2.2.1. Évalué à 5.
Patch for debian bug #350396: "amule depletes entropy pool".
À noter qu'aMule dépend maintenant de la bibliothèque crypto++.
[^] # Re: Argumente...
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Questions trollesques sur GNOME & cie. Évalué à 2.
Moi je n'ai pas Nautilus d'installé sur mon système et lister tous les fichiers de /usr/bin avec le sélecteur de fichier GTK met effectivement 3 plombes.
Preuve que ta démonstration n'en est pas une.
[^] # Re: Site HS ?
Posté par Jérôme Pinot (site web personnel) . En réponse à la dépêche Firefox 3 est publié. Évalué à 4.
On vient tout juste de passer la barre des 2,5 millions de téléchargements. Impressionnant.
[^] # Re: Hmmm...
Posté par Jérôme Pinot (site web personnel) . En réponse au journal Slackware, E17 et NVIDIA. Évalué à 5.
Je crois que tu sous-estimes légèrement la difficulté de la tache. Il y a de plus en plus de projets libres qui n'arrivent plus à suivre le rythme de développement du noyau.
Juste un exemple : le projet grsecurity, qui essaie de renforcer la sécurité du noyau, vient de jeter l'éponge : trop de travail. Ils vont se rabattre sur le noyau LTS d'Ubuntu. Tant pis pour les autres. http://grsecurity.net/pipermail/grsecurity/2008-May/000927.h(...)
Ce n'est pas un problème libre/propriétaire, car au final, NVIDIA sort bien un nouveau driver régulièrement ; mais force est de constater, que sans l'appui financier d'une entreprise, il deviendra de plus en plus difficile de contribuer sérieusement au noyau. Je ne parle pas de coder des nouvelles choses, mais bien de maintenir son code.
Le diff entre Linux 2.6.20 et 2.6.25 fait 143Mo (19 319 patches), ce qui fait une moyenne (je ne l'ai pas inventé :-) de 42 patches par jour, ça donne de quoi s'occuper...