Gabriel Linder a écrit 175 commentaires

Header ou pas, çà fait quand même partie du projet, je ne vois pas de quel droit il pourrait décider de virer la license... Quand à l'affaire précédente, je suis bien d'accord, c'était un fiasco.

Justement, ce n'est pas l'auteur original qui a décidé de changer de license.

Donc quand un dev BSD pique du code GPL pour avoir un driver qui marche, mais pas encore terminé vu qu'il est censé être sous license BSD, dans le but d'avoir des retours en attendant de recoder la partie GPL, on le lapide en place publique.

Mais quand c'est un dev Linux pique du code BSD pour le mettre en GPL (alors qu'il aurait très bien pu le laisser sous BSD, de plus c'est illégal vu que la license BSD impose de laisser le copyright, les conditions et le disclaimer non ? cf [1] et [2]), on rit au nez des dev BSD en leur montrant des gros manches à balai en faisant des gestes obscènes ? La GPL a pourtant un paragraphe qui indique qu'on doit transmettre les mêmes droits que ceux qu'on a reçus originellement : " For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. "

Faut arrêter les conneries, hein. Quand à ce qui se disait plus haut, dans un BSD de base il ne doit guère y avoir que grep, gcc et leurs dépendances (je pense en particulier à binutils et gdb) sous GPL, et encore, des projets sont en cours pour s'en débarasser [3].

Et non, je n'utilise pas OpenBSD, çà me met juste hors de moi de voir la bêtise humaine oeuvrer une fois de plus dans un domaine qui m'est cher.

[1] http://www.mail-archive.com/misc@openbsd.org/msg46729.html
[2] http://www.mail-archive.com/misc@openbsd.org/msg46742.html
[3] http://www.freebsd.org/projects/ideas/#p-bsdelftools

L'article est titré "Linus contradicts OpenBSD founder on Intel TLB issue" et fait comme si Theo avait fait une montagne des TLB, c'est en ce sens qu'allait mon commentaire. Que Linus dise que le problème des TLB n'est rien est parfaitement correct, et je n'irais certes pas le lui reprocher.

De plus Linus contredit De Raadt sur les bugs des Core 2 Duo [1] en disant que " le problème des TLB n'est rien du tout " sauf que quand Theo disait " bugs critiques et dangereux " il ne pensait pas du tout aux TLB mais en visait d'autres... Bref il lit et commente ce qu'il veut bien lire et commenter, sa parole étant reprise comme la seule valable.

[1] : http://article.gmane.org/gmane.os.openbsd.misc/126235
et l'article dont ils parlent : http://blogs.zdnet.com/Ou/?p=559

Normal, puisque vim n'est pas un éditeur pour masochistes mais pour personnes normalement constituées et recherchant l'efficacité, et non pour espèces de cyborgs sortis tout droit de Ghost in the Shell...

De ce que j'en ressens le système est plus "fluide" et les CPUs moins sollicités, la charge étant mieux répartie entre les coeurs (ceci ne concerne que mon P4 HT, je n'ai pas encore testé sur un vrai dual core, je prévois de recompiler le kernel de mon laptop ce soir). Avec SD il était habituel de voir un core à 90% et l'autre à 0% lors des compilations de kernels, avec CFS les deux cores tournent à un rythme identique. Sous forte charge les applications sont plus rapides à se lancer qu'avec SD (genre xterm et top pour voir ce qui se passe).

Tu as extrêmement bien résumé la situation (de ce que j'en sais), à un détail près : le gus s'appelle Ingo Molnar, pas Molvar :)

Tant mieux, parce que le système est vraiment beaucoup plus réactif avec ce scheduler (même par rapport à SD, que j'utilisais jusqu'à présent mais maintenant que -ck n'est plus maintenu il faut bien se mettre à jour) !

$ cat /proc/version
Linux version 2.6.22.1-cfs-v19-dargor (root@oblivion) (gcc version 4.1.2) #1 SMP PREEMPT Wed Jul 11 09:52:58 CEST 2007

Idem, sauf que j'ai plutôt tendance à piocher au hasard, et à rejeter si çà ne me plait pas dans les dix secondes.

À l'opposé dans un magasin d'informatique je peux passer trois heures à tout remuer pour trouver *le* disque dur / la barette mémoire / vous voyez où je veux en venir qui fera mon bonheur, comme quoi tout dépend de ce qu'on achète :)

Dans le même genre y'a menumaker[1], que j'utilise depuis mon passage à fluxbox et qui marche très bien. Je ne connaissais pas dmenu, je vais l'essayer :)

[1] : http://menumaker.sourceforge.net/

Mince, le Gouvernement m'a cloné à l'insu de mon plein gré !

Bon la seule différence c'est que moi si je porte une "marque", c'est involontaire (là les baskets c'est des adidas, achetées vite fait sans trop faire gaffe à ce que c'était), donc je ne saurais en citer :p

Il y a eu de l'activité dans le svn de freerock il y a quelques semaines (bump de numéros de version en vue de générer de nouveaux paquets), mais plus rien depuis. GWare lui semble tout à fait mort, par contre. Wait and see...

Quand à inclure le travail de dropline (vu que c'est le seul activement maintenu du lot) c'est hors de question pour la bonne et simple raison qu'à dropline ils se croient plus malins que tout le monde et recompilent de nombreux paquets de base de slackware (on dira notamment shadow) uniquement pour le support de PAM, qui n'est pas inclus dans slackware et c'est une bonne chose, merci. Ils fournissent également des mises à jour de gros paquets comme xorg, recompilés en "-march=i686 -fomg-unroll-loops" parce que çà va plus vite.

N'essaie donc pas de me décourager... ;)

Mais non, il a seulement séparé /etc/rc.d/rc.* dans un autre paquet que le binaire sysvinit. Un init sysV, quelle horreur voyons !

Perso je préfère utiliser jhbuild pour avoir l'ordre de compilation (c'est çà le plus gros souci de gnome, l'ordre dans lequel compiler tout leur bord^W^W^Wles dépendances) puis compiler moi même... gargnome comme jhbuild n'arrivent jamais au bout d'une compilation automatisée :)

PS : un jour je mettrais en ligne mes scripts de compilation, mais faut déjà que je réinstalle mon laptop :p

Générer du code dynamiquement est crade et dangereux, un programme utilisant ceci subira un kill sauvage et bien mérité sur un kernel PaX[1]/Grsecurity[2] configuré correctement. Après on peut bien autoriser l'exécution de tels programmes avec paxctl, mais bon...

Sinon il reste la possibilité de t'interfacer avec un interpréteur de script, comme dit plus haut.

[1] : http://pax.grsecurity.net/
[2] : http://www.grsecurity.net/

Il manque Lua, simple et léger : http://www.lua.org/about.html

Pour l'instant, il est un peu vide, essentiellement composé de capture et de textes en grosses lettres.

Parfaitement adapté aux Ubuntistes, donc. :)

Hé, mais c'est bien çà. Merci !

En plus ils n'aiment pas Slackware, ces gens là mériteraient d'être flagellés en place publique. Oui monsieur.

Mais vous avez quoi contre bitlbee ici ? Il gère juste ce qu'il faut, à savoir l'envoi et la réception de texte. Pour les fonctionnalités kikoolol c'est sûr qu'il faut se tourner vers un autre client, mais là c'est à vous de voir si vous avez vraiment besoin de voir l'avatar/le statut/les wizz/etc de vos correspondants (ou de voir leurs têtes en kikoocamasv/les entrendre en kikoojaiunmicromdr, je sais pas vous mais moi çà m'empêche de coder). En fait il ne manque que le transfert de fichiers, mais bon pour çà j'ai un serveur ftp. Et n'importe qui peut utiliser un serveur client ftp, si on lui explique correctement :)

Bon vous aurez deviné ce que j'utilise, je ne m'éternise donc pas et je sors, il fait beau...

Puis tu désactives Composite et AIGLX, çà devrait suffire.

Héhé je vois, le piège ne devait pas être décrit à l'époque de ce code :)

Pour ma défense ce code était un code de transition : j'essayais de donner aux RichEdits la même bordure qu'aux autres edits (voir le screen plus bas) en vue de l'adapter par la suite pour Delphi. D'où l'allure très gruik du code, mais j'assume !

Pour voir la différence entre les bordures : http://www.delphifr.com/codes_image/normal/28659.aspx à gauche = apparence par défaut, à droite = apparence modifiée... Parce que çà faisait méchamment tâche de laisser un richedit avec l'apparence 9x au milieu de contrôles utilisant l'apparence XP.

Çà m'a rappelé d'émouvants souvenirs que je vais vous faire partager, pour la peine. Y'a des messages d'erreurs plus ou moins liés à Windows, et aussi un peu d'APIs et documentation Win32 juste pour rire :)

- Quoi, je ne suis pas administrateur (erreur obtenue en cliquant sur le bureau, après avoir désactivé les icônes) ?
http://athanatos.free.fr/Administrateur.gif

- MS Installer et son contrôle d'erreurs...
http://athanatos.free.fr/MSI.png

- Appel d'API qui réussit, mais qui ne renvoie pas la valeur prévue par MSDN en cas de succès (faites pas gaffe aux assert, c'était juste pour éviter de taper des if partout)
http://athanatos.free.fr/SetWindowLong.jpg

- MS qui se fout de nous (pas un message d'erreur, mais...) :o)
http://athanatos.free.fr/axiome.jpg

- .Net a eu le mérite d'apporter des messages d'erreurs explicites
http://athanatos.free.fr/dotnet.gif

- MS qui se fout de nous bis :o)
http://athanatos.free.fr/error_success.gif

- Message d'erreur interdit aux -18 ans
http://athanatos.free.fr/pornows.gif