Gaël Le Mignot a écrit 812 commentaires

"A Freer Cousin"

Peut-être est-ce une réaction à l'utilisation de BitKeeper par Linus et une partie des développeurs du noyau ?

-1 ça n'apporte pas grand chose

il faut que le µnoyau sur lequel repose le Hurd supporte plus de matériel

Ce sera fait d'ici quelques mois avec le passage à OSKit Mach. Sinon, l'un des gros avantages des µ-noyau (et de Mach) c'est qu'il possible d'implémenter énormément de drivers uniquement en user space.

Linux est bien trop populaire et implanté pour que GNU remplace GNU/Linux.

Le passage de GNU/Linux est presque transparent (ou le sera lorsque les problèmes du Hurd seront corrigés), et une immense majorité d'applications ne demandent qu'un portage minimal. En particulier avec la Debian GNU/Hurd (http://www.debian.org/ports/hurd/index(...)).

Les éditeurs ont déjà du mal à se tourner vers Linux, je vois pas pourquoi ils se tourneraient plus vers le Hurd et son µnoyau

Pour des raisons de sécurité ? De fiabilité (lorsque tout marchera bien) ? Pour tous les avantages qu'il apporte(ra) ?

Non, le titre est juste, GTK 2.0 est sortie dimanche soir si je me souviens bien. Peut-être la news date t'elle d'avant, mais GTK 2.0 est bel et bien là ! A vos gcc en attendant les paquets officiels !

La Debian possède aussi des paquets fixés, dans la Sid en tout cas:

zlib (1:1.1.3-19.1) unstable; urgency=high

* Non-maintainer upload
* Apply patch for double-free bug

-- Matt Zimmerman <mdz@debian.org> Sun, 10 Mar 2002 23:52:20 -0500

Hum ? Tu veux faire du S-NAT quoi ?

iptables -t nat -A POSTROUTING -i eth0 -o ppp0 -j MASQUERADE devrait faire le boulot normalement, ou alors j'ai mal compris la question...

Moi perso j'utilise Netfilter pour faire du NAT + firewall depuis que j'ai l'ADSL (presqu'un an...), et j'ai récemment mis en place du QoS pour deux choses:
* limiter le débit sortant de mon serveur Web et de mon serveur FTP à 100kb/s (sur les 128 au total)
* augmenter la priorité des paquets ACK et des paquets à destination du port 22 (ssh)

-1 car ma vie n'intéresse pas grand monde...

CorbaTrace est implémenté en Java, et dans la doc je n'ai vu aucune référence à une méthode pour l'utiliser avec des applications créées dans d'autres langages (C++ par exemple).

Est-ce que quelqu'un peut me dire s'il existe un moyen de l'utiliser avec du C++ ou pas ?
Merci ;)

Le plus simple c'est de ne pas utiliser le module ipt_conntrack_irc, les DCC pourront ne plus marcher mais c'est tout...

Euh... STFW ?

Le SSSCA = "Security Systems Standards and Certification Act" est une loi américaine qui vise à obliger l'utilisation de composant anti-piratage d'un bout à l'autre de la chaine (disque dur, OS, carte son, ...)
cf http://www.eff.org/IP/SSSCA/,(...) une pétition sur http://www.petitiononline.com/SSSCA/petition.html(...)

Sinon, c'était pas le PDG de Disney qui avait dir que les lois de protection de la vie privée étaient son pire ennemi ?

Et oui, je tiens à rappeler que commenter et documenter son code, expliquer ce qui est fait, comment et pourquoi est *très* important dans un projet de cette ampleur, contrairerement à ce que prétend un certain A.A. (cela étant dit sans aucune animosité particulière... ;) )

Et quand c'est le mainteneur du sous-système qui envoie le patch ? Comme Rik pour la VM au début du 2.4 ?
Je suis parfaitement conscient que Linus ne peut pas justifier tous ses refus, mais ça pose quand même un réel problème, AMHA.

Et bien je dirais qu'il y a réellement quelques problèmes, mais qu'ils ne sont pas du tout aussi important qu'ESR ne le laisse croire. Le plus gros problème qu'il y a eu AMHA est sur la VM, où Linus a ignoré tous les patchs de Rik du noyau 2.4.0 au 2.4.9, ce qui fait que la VM des noyaux "officiels" < 2.4.10 marche très mal, alors que les noyaux -ac de la même période, avec les patchs de Rik, marchent beaucoup mieux (enfin, beaucoup moins mal diront certains).

Sinon il est vrai aussi que Linus (en général) ignore les patchs qui ne lui plaisent pas, au lieu de signaler la raison de son refus à l'auteur du patch (que celui-ci puisse corriger), mais je comprends qu'il n'aie pas du tout le temps de faire ça.

Il faut savoir qu'il existe déjà des patch-penguins (= des personnes chargées de centraliser, tester, nettoyer les patches dans une branche parallèle du noyau avant de les soumettre au mainteneur), il s'agit d'Alan Cox pour la branche 2.4 et de Dave Jones pour la branche 2.5. Ils n'ont aucun statut "officiel", mais ils font néanmoins un très bon boulot.

Le principal problème est que Linus et Marcelo veulent tous les deux contrôler et vérifier au moins rapidement l'ensemble des patchs qu'ils intégrent (ce qui est compréhensible) et qu'avec l'accroissement du nombre de contribueurs ils n'ont plus le temps de les analyser tous et encore moins d'expliquer les raisons de leur refus lorsqu'un patch ne convient pas (Linus a tendance à discarder les patchs sans rien dire).

Le problème est assez compliqué et les débats sur la LKML pas toujours facile à suivre, mais c'est en gros ce que j'ai compris.

Euh, j'aimerais bien t'y voir à maintenir une branche du noyau Linux. Tu crois que c'est facile ? Tu as une petite idée de la masse de boulot que ça représente ? Alors avant de porter un jugement sur Marcelo Tosatti, essaie de te renseigner.

Marcelo s'occupe du noyau 2.4 depuis la sortie du 2.4.15, il a donc releasé le 2.4.16, 2.4.17 et 2.4.18. Il a commis une bourde récemment en oubliant un "morceau" du 2.4.18-rc4, mais les erreurs ça arrive à tout le monde non ? Alors évite de critiquer une personne qui fait un boulot immense juste parce qu'un jour il a fait une petite bétise.

Si tu lisais la news: " Des trous de sécurité au niveau de l'upload de fichiers", daCode n'utilise jamais la fonction d'upload de fichiers de PHP, il n'y a donc aucun risque...

t'as mis en -1 donc moi aussi ;)

De toute façon ce n'est plus Linus qui s'occupe de la branche 2.4 mais Marcelo Tosatti; Linus ne s'occupe que du 2.5.

Marcelo Tosatti est assez surchargé, et c'est compréhensible, et c'est pour cela qu'Alan Cox maintient sa branche (-ac) dans laquelle il intègre plus de patchs, qu'il soumet à Marcelo lorsqu'il les trouve assez propres et testés (note: je simplifie énormément le fonctionnel réel...)

Pour être correct et précis: le noyau 2.4.18 n'est ni le 2.4.18-rc3 ni le 2.4.18-rc4; il y une partie du patch -rc4 dedans mais pas la totalité.

Le pb que ce patch corrige est lié à l'exécution de binaires statiques sur certaines archis (x86 non comprises). Donc, pour 95% d'entre nous qui utilise GNU/Linux sur un x86, le 2.4.18-rc3, -rc4 ou -final revient au même.

Pour ceux qui ne sont pas sur x86, il vaut mieux prendre le -rc4.

En parlant de la gestion de la mémoire sous Windows, sous 9x le fait de lancer et de quitter le notepad coûte définitivement 64K de mémoire jusqu'au reboot. Quelqu'un sait si ça fait la même chose sur NT/2k ?

Malheureusement il est pas encore complètement stable, si Mozilla segfault au moment de démarrer Mozilla Mail il faut effacer le ~/.mozilla/..../XUL.mfasl à chaque fois avant de lancer Mozilla.

Oui, c'est une loi à la c*** et complétement inapplicable, et pour les processeurs, et bien tu as un projet nommé le SSSCA (Security System et Service Control Act ou un truc comme ça) qui vise à obliger l'utilisation de composant "anti-piratage" d'un bout à l'autre de la chaine (disque dur, processeur, carte son, enceintes, cartes vidéos, OS, ...) :(

C'est exact en France, mais pas aux USA. Le DMCA interdit de donner aux gens le moyen de contourner les protections, et pas seulement le "piratage" en lui-même. C'est pour cela que DeCSS est illégal là-bas, parce qu'il *peut* être utilisé pour contourner une protection.

L'arbre CVS de Mozilla est fermé en prévision de la 0.9.9 qui ne devrait pas tarder, les premières pré-versions du 0.9.9 devraient apparaitre dans le début de la semaine suivante... c'est le moment de tester et de faire des bugs reports, avant la sortie de la 0.9.9 (denière milestone avant le 1.0 si tout ce passe bien) !

Sinon, la Woody est toujours en phase de gel, on peut donc considérer que c'est une béta permanente :)

[je répond aussi au commentaire suivant]

Si MS est sommé de donner le code source complet de Windows, il y a un moyen très simple de vérifier qu'il s'agit bien du code original et pas d'une version trafiquée: le compiler avec la même version du compilateur et les mêmes options, et faire un "diff" sur les binaires.

Après bien sur il y a le problème de l'impartialité des experts qui peut être difficile à garantir...

mwarf ;)
En ce qui me concerne, mes propos, que ce soit sur le wiki (rendez-nous le wiki!!!), la tribune, les commentaires, #linuxfr@OPN ou les mailinglists sont copyleftés.

Donc on dit pas (c) Kilobug mais euh (comment on le fait le c retourné ?) Kilobug. Disons Copyleft (c) Kilobug alors :)

Bon, -1 c'est nul

Sans vouloir lancer/rentrer dans un troll, sous Gtk aussi les thèmes peuvent se "compiler", puisque le theme engine peut faire appel à des .so externes.

Maintenant c'est très limite niveau sécurité comme manip, il est donc préférable d'avoir un moteur suffisament puissant pour éviter d'avoir à inclure du code dans les thèmes eux-mêmes (et favoriser ainsi l'intégration du thème dans un environement mixte, par exemple lors d'un /home monté en NFS sur des machines d'architectures différentes, un utilisateur doit avoir une version du thème par archi, ce qui n'est pas très pratique).