Krunch a écrit 4025 commentaires

Je dirais plutôt que le fait que ce texte n'existe pas est une observation. Une conclusion serait par exemple que tu es le seul bon programmeur sur le net. Une autre serait qu'utiliser des printfs pour debuger un programme est considéré comme tout à fait correct par la majorité des programmeurs.

C'est pas parce qu'un tel article existerait déjà que celui qui l'aurait écrit serait un bon programmeur. Il y a plein d'articles très mauvais écrits par des mauvais programmeurs. Que cet article ci soit bon ou non, c'est au lecteur de juger mais si l'article existait déjà je n'aurais pas eu à l'écrire. L'intérêt de l'avoir écrit c'est que maintenant qu'il existe, j'aurai juste à ressortir le lien quand le sujet sortira dans une conversation plutôt que d'expliquer mon point de vue pour la 42ème fois.

utiliser un debugger apporte aussi son lot d'inconvénients et n'est pas forcement un meilleur choix.

D'ailleurs, pour trouver un bug, même les solutions les pires sont acceptables si les meilleures n'ont rien donné...

C'est bien comme ça que je l'entend. Il n'y a pas de solution miracle. Mon journal tente de montrer au programmeur débutant qui ne connait que le printf debugging les limites de cette méthode.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

À la base, techniquement, au niveau sécurité, j'ai un peu de mal à voir en quoi Windows NT et ses descendants sont moins bien conçus que Unix/Linux. Les systèmes de privilèges ont l'air assez similaires en fin de compte. J'ai plutôt l'impression que les problèmes de virus de Windows sont dûs à une configuration par défaut trop laxiste, des utilisateurs qui ne comprennent pas ce qu'ils font et une grande distribution de l'OS (ce qui augmente la motivation des attaquants).

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

[Microsoft, ] si soucieux de son image

Si c'était le cas ça se saurait. Tu confondrais pas avec Apple par hasard ?

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

$ awk -F: '$1 ~ /^plop$/ { print "cet identifiant existe" }' < /etc/passwd

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

La libc GNU permet aussi d'avoir un backtrace depuis le programme lui même (sans fork()er gdb par contre). Personnellement je trouve ça assez gadget. Pourquoi rajouter du code si on peut le faire avec un programme externe (et quelques lignes dans le Makefile si on est vraiment fainéant) ?

http://www.gnu.org/software/libc/manual/html_node/Backtraces(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ben il dit bien qu'il sait se servir de gdb et qu'il l'utilise tout le temps. Juste qu'il l'utilise pas n'importe comment.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un peu comme le « Avoid debuggers » de hacknot.info :

I've noticed that habitual use of symbolic debuggers also tends to discourage serious reflection on the problem. It becomes a knee-jerk response to fire up the debugger the instant a bug is encountered and start stepping through code, waiting for the debugger to reveal where the fault is.

Un debugger n'est pas une solution miracle non plus, c'est qu'un outil qui peut aider quand on l'utilise intelligemment (j'ai aussi l'impression que « single-stepper » est rarement un bon moyen de trouver un bug). Dans le mail de Torvalds je ne vois pas non plus où il dit que le printf debugging c'est supair.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Non t'as raison j'ai oublié de passer le fichier en argument à vi.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pas besoin d'exceptions pour avoir un backtrace sans relancer le programme. En C, une fois que t'as ton coredump, un passage par gdb suffit pour retrouver l'endroit du segfault ou de l'abort(3) (assert(3) appelle abort(3) quand son argument est faux).

Concernant les exceptions, je recommande les lectures suivantes :
http://www.joelonsoftware.com/items/2003/10/13.html
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.(...)
http://blogs.msdn.com/oldnewthing/archive/2005/03/17/397468.(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Par contre $() est spécifique à Bash alors que `` est censé être disponible sur tout shell compatible sh.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Voilà https://linuxfr.org/~Krunch/22577.html

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Personnellement je pense que le principal intérêt des jeux vidéo libres est leur durée de vie. La plupart des jeux propriétaires n'ont des utilisateurs que pendant une durée relativement courte (2 ou 3 ans ?) alors qu'un jeu libre abouti est joué pendant bien plus longtemps.

Une raison pour cela est que la distribution du jeu coûte de l'argent à l'éditeur et après un certains temps, vendre un jeu coûte plus d'argent qu'il n'en rapporte. Ce facteur a tendance à s'estomper avec les systèmes de distribution en ligne (Steam,...) mais il est virtuellement inexistant pour les jeux libres gratuits.

Même en faisant abstraction du coût de la distribution, lorsqu'un jeu n'est pas maintenu, il devient rapidement inutilisable sur les nouvelles plateformes. Je ne suis sans doute pas le seul a avoir quelques jeux au fond d'une armoire auxquels j'aimerais bien pouvoir rejouer mais qui ne tournent pas sur autre chose que Windows 9x. Bien sûr il existe des projets (dosemu, wine,...) permettant de pallier à ce problème avec plus ou moins de succès mais c'est rarement la panacée. D'un autre côté, un jeu libre sera toujours jouable sur la plateforme du moment tant qu'il y aura au moins une personne assez motivée pour vouloir y jouer. Enfin, en théorie. En pratique il faut quand même un certains nombre de personnes techniquement compétentes mais ça reste possible bien plus facilement que pour un jeu propriétaire.

Une alternative qui me semble viable est de garder le jeu sous une licence propriétaire pendant quelques années avant de le passer sous une licence libre pour la postérité. C'est un peu ce que fait id Software mais de manière encore un peu trop limitée à mon goût puisque les données restent sous licence propriétaire.

À noter que cet argumentaire reste valable pour les logiciels qui ne sont pas des jeux mais j'ai l'impression que les logiciels « classiques » sont beaucoup plus interchangeables que les jeux. Et puis en pratique les logiciels propriétaires « classiques » ont généralement une durée de vie bien plus correcte que celle des jeux propriétaires.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Et l'Artistic License elle compte pas non plus ? http://dev.perl.org/licenses/artistic.html

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Lisp + Perl = Haskell

Sinon dans la liste des langage intéressants qu'il faudrait que j'apprenne un jour il y a Erlang, Objective-C et Smalltalk.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Un autre gestionnaire de fenêtres dans la même veine que Ion mais qui pousse l'idée un peu plus loin : WMII http://wmii.de/wmii/

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

C'est à mettre dans le Makefile (CFLAGS += -D_XOPEN_SOURCE=500), pas dans le code.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Je pense que la vrai solution est d'avoir une méthodologie de programmation assez rigoureuse : abuser des assert(3), bien vérifier toutes les valeurs de retour, compiler avec -W -Wall -pedantic, vérifier régulièrement que rien ne cloche avec Electric Fence, Valgrind et d'autres compilateurs (celui d'Intel donne beaucoup plus de warnings que GCC par exemple, il est pas libre mais il est disponible gratuitement sous certaines conditions), définir un coding style et s'y tenir,...

Programmer proprement quoi. Une fois qu'on fait ça, retrouver un bug devient généralement bien plus facile pour la simple raison qu'on le trouve plus tôt dans le développement.

Voir aussi le guide superflu de programmation en langage C :
http://docs.happycoders.org/orgadoc/dev/C/c-superflu.pdf

Pour ce qui est de l'affiche des structures des données, c'est plutôt du ressort du debugger (ddd marche bien pour ça) même s'il est vrai que dans certains cas ça reste plus pratique d'avoir une fonction d'affichage à côté.
À ce sujet j'ai commencé un vague argumentaire à l'encontre du "printf()-debugging". Faudra que je pense à en faire un vrai texte un jour.
http://www.krunch.be/vrac/txt/printf-debugging-harmful

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Pour ça, le t-shirt « Knuth is my homeboy » suffit apparement http://johnny.ihackstuff.com/gallery2/gallery/view_photo.php(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Justement, c'est un test : seul les bons élèves peuvent accéder au réseau :)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

En tout cas, ce sera sûrement très différent de ce qui t'ennuie actuellement.

Pour changer de la programmation « classique », il y a le fonctionnel aussi. Je suggère de commencer par du Scheme.

http://www.cabochon.com/~stevey/blog-rants/tour-de-babel.htm(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

$ zcat user-ct-test-collection-* | perl -F'/\t/' -ane'print if $F[1] =~ /linux/' | wc -l
501

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Ca doit être l'interface web qui déconne, moi j'en vois 501 (2914 si on compte aussi ceux qui ont « linux » dans l'url cliqué).
Par ailleurs :

ClickURL - if the user clicked on a search result, the domain portion of the URL in the clicked result is listed.

Pourtant il y en a certains (au moins un) où on a l'url complet :

user-ct-test-collection-03.txt.gz:3520999 acheter des ordinateurs 2006-04-07 12:33:40 1 https://linuxfr.org/2004/05/13/15986.html

Sinon à force de grep(1)er, on tombe sur des trucs marrants.

6959321 privacy issues 2006-03-16 19:55:34 2 http://www.cdt.org
6959321 identity theft interesting facts 2006-03-16 23:44:35 6 http://slashdot.org
4246170 get laid locals 2006-05-04 17:51:55 15 http://linuxfromscratch.org
3520999 paintings of paul gaughin 2006-03-01 20:33:49 27 http://www.montanawatercolorsociety.org
3520999 where have you been where are you now where are you going 2006-03-01 20:35:27
3520999 gaughin tu vas ou 2006-03-01 20:37:46 2 http://jardindemuse.over-blog.net
3520999 ma vie sociale 2006-04-01 21:08:24

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

mais un truc qui me fait doucement sourire, c'est que ces logs anonymisés des recherches AOL ne sont rien de plus ni de moins que :
http://linuxfr.org/~plagiats/6919.html

Bien plus quand même. Un identifiant est associé à chaque utilisateur alors que dans le cas de Lycos Voyeur, tu n'as que des requètes et rien qui permette de les lier entre elles.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

Anyone who wants to play NSA can start datamining for terrorists. Let us know if you find anything.

http://www.schneier.com/blog/archives/2006/08/aol_releases_m(...)

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

L'équivalent d'autoexec.bat il me semble que ça serait de le mettre en script d'init. Par contre ça veut dire que quelque soit la personne qui démarre l'ordinateur, il devra répondre aux questions avant même de pouvoir se logguer et que ceux qui se loggueront après n'auront pas besoin de le faire.

pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.