Johands a écrit 87 commentaires

Faut pas être si négatif concernant le manque de nouveautés côté utilisateur lambda. Avec un peu de chance et beaucoup de sueur de Jindrich Novy, on pourra bientôt bénéficier de TexLive 2010 sous Fedora 14.

cf: https://bugzilla.redhat.com/show_bug.cgi?id=488651#c161

Ça nous changera de l'actuel TexLive 2006. (:ironie:)

duh, le dernier exemple est l'exemple de trop !

Si j'ai lu correctement, la méthode func est "bound" / liée mais cela ne signifie pas que self soit figé. On peut visiblement faire appel à a2.func.im_func avec self == a1.

Je n'ose même pas imaginer comment un tel découplage pourrait-être exploité...

C'est quoi ce troll en plein Jeudi ?

Ton exemple du graphiste est mauvais : ton graphiste veut Gimp sur un ordinateur sans trop de bugs ? Il installe Arch/Sid/Fedora et se contente d'y ajouter un unique paquet Gimp. Fin de l'histoire.

La stabilité prend plus de sens quand il s'agit, par exemple, d'un serveur faisant tourner 24/7 une application PHP/MySQL ou autre. Ton client veut utiliser la dernière version de l'application ? Tu dois te taper la mise à jour et la reconfiguration manuelle de MySQL, php.ini et Apache. C'est un peu plus long que d'installer le dernier wesnoth ou Gimp et personnellement je n'ai pas envie de passer tous mes après-midi à ré-écrire mon httpd.conf.

je souhaite simplement privilégier une philosophie très KISS sur ma machine (ce n'est donc pas une question d'occupation mémoire).

Tu as bien plus de courage que moi. J'ai succombé à la facilité et je laisse d'autres personnes empaqueter et pré-configurer mon gnu/gconf/linux, pour le meilleur comme pour le pire. C'est surement aussi la raison pour laquelle j'utilise majoritairement les outils en ligne de commande.

D'ailleurs dans la série du "pire", ils manquent actuellement trop de paquets sous Fedora13 pour tenter de compiler LaTeXila. Mais des MAJs sont à venir très prochainement. Patience, patience donc …

C'est des maths à prendre en LaTeX en temps réel. Là est la contrainte. Et du coup, il me faut un éditeur qui me fasse gagner beaucoup de temps.

Au temps pour moi. Si tu as un soucis apparenté à de la dyspraxie (chose qui m'est totalement inconnue), je ne sais pas si un vim sous amphétamines t'aidera réellement. Tu perds les capacités click-o-dromesques de kyle/latexila pour gagner au mieux trois snippets pré-configurés et l'interface vi-esque habituelle.

Je pense que la couche d'abstraction commence avec LaTeXila. Le soucis des dépendances supplémentaires vis-à-vis de GSetting, libunique ou rubber me semble vain, tout du moins avec la puissance des machines actuelles.

Si tu n'aimes pas, rien ne t'empêche de simplement rédiger tes documents \LaTeX avec ton éditeur de texte préféré (vim, emacs, …) et un exemplaire de [http://tobi.oetiker.ch/lshort/lshort.pdf] ouvert à côté comme référence.

Personnellement, je te déconseillerais vim-latex (trop lourd, trop complexe). Regarde plutôt du côté de snipMate pour la pseudo-auto-complétion et de latex-mk pour la compilation.

Effectivement, mais d'après ce que j'ai compris, en plus de créer les nœuds dans /dev il émet des signaux du genre "le périphérique A vient d'être branché".

HAL/DeviceKit/udisk sont chargés d'écouter udev et de répondre aux signaux en conséquence.

Avant de partir dans un délire total en réinventant la roue, suis le conseil précédent et assure toi que ta distribution ne le fait pas déjà automatiquement.

Normalement, les distributions modernes utilisent udev/DeviceKit. Si ton noyau n'a pas udev, c'est très très louche.

Si tu veux un contrôle plus fin (filtrer les clés USB en fonction de leur UUID par exemple), cette question a déjà été posée sur linuxFR. Cherche les forums à propos des règles udev.

Aucune idée. Mais de toutes façons, qui s'en soucie de python3k ? Personne !

Même pas les développeurs python eux même, vu l'état du "Python 3K - Unicode HOWTO":

This HOWTO discusses Python 2.x’s support for Unicode, and explains various problems that people commonly encounter when trying to work with Unicode. (This HOWTO has not yet been updated to cover the 3.x versions of Python.)

source : http://docs.python.org/py3k/howto/unicode.html

// Mauvais humour mis à part:
Oui le "bug" précédent est corrigé dans python3k et oui python3k traite tous les 'string' comme des objets Unicode. Reste plus qu'à éviter de confondre b"hello world" avec "hello world".

En pleine période de crise financière, les gouvernements se remuent le popotin pour [trouver de nouveaux financements]. Et je [pense] qu'une guerre ouverte entre détenteurs de brevets soit une bonne chose pour [les caisses de l'USPTO et l'INPI].

… De plus, il est bien connu que le niveau de développement d'un pays se mesure en comptant le nombre de brevets déposés sur son sol. En cette période de crise et de concurrence exacerbée, la taille des porte-feuilles de brevets pourrait déterminer l'issue de la bataille …

Mais encore une fois, je veux croire que quelqu'un me prouvera que j'ai tort.

J'ai rencontré un problème similaire récemment, mais avec stdout. Dans le doute voici ce qui bloquait sous Python 2.x:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys
import locale

print "preferred encoding = {0}".format(locale.getpreferredencoding())
print "but ..."
print "sys.stdout.encoding = {0}".format(sys.stdout.encoding)
print "sys.stdin.encoding = {0}".format(sys.stdin.encoding)
print "therefore 'print u'unicode string' results in ..."
print u" *** Python, çuckß *** "


Maintenant, si tu fais tourner le script précédent avec :
bash $ LANG="fr_FR.UTF-8" python script.py
bash $ LANG="C" python script.py
bash $ LANG="en_GB.UTF-8" python script.py | cat
bash $ LANG="en_GB.UTF-8" echo "foobar" | python script.py
bash $ LANG="en_GB.UTF-8" echo "foobar" | python script.py | cat

… tu vas obtenir 5 résultats différents.

Je suppose que ta crontab fait tourner ton script dans un environnement particulier (locales ou LANG différents) ou, pire encore, que tu utilises des pipes ! Essaie de faire tourner le script précédent en remplaçant stdout par stdin et de logger son résultat dans un fichier externe pour comprendre le schmilblick.

Plus d'info: http://docs.python.org/howto/unicode.html#reading-and-writin(...) (page qui peut se résumer avec a) toujours utiliser string.decode(charset) sur les entrées b) toujours utiliser string.encode(charset) sur les sorties)

… mais qui ose encore dire que python est simple ???

Tu veux dire que me suis crev.. le c.. pour rien ?

Je viens de mettre à jour mon weboob via git. J'ai accès à la jolie nainterface Qt et au backend "arte" mais impossible de regarder les vidéos avec.

Donc non, ton script python est utile. D'ailleurs j'adore son interface texte, avec le petit invité de commande et la mini REPL ;)

Dans le doute, quelqu'un pourrait-il me confirmer si ce qui suit est correct :

L'histoire du SPF, ça implique qu'il est nécessaire de passer par le SMTP correspondant à chacune de ses adresses e-mail si on ne veut pas être marqué comme spam. Exemple, si j'envoie en tant que toto@laposte.net, titi@ovh.com ou tutu@gmail.com, je dois contacter respectivement smtp.laposte.net, smtp.ovh.com et smtp.gmail.com ?

(/trop la flemme de reconfigurer son postfix …)

Je croyais que l'université était le lieu idéal pour apprendre à utiliser un système d'exploitation alternatif : plein de temps libre pour geeker sur un terminal et de gens curieux tout autour pour s'entre-aider.

Mais bon, ici s'arrête la discussion :

- ubuntu ==> aucun rapport avec la choucroute !

- les statistiques sur les systèmes d'exploitation indiquent This table documents whether first-year students identified their primary computer as running a Windows, Mac (or Windows on a Mac), or other operating system (such as Linux).. (Traduction: «ce tableau référence les étudiants de première année utilisant comme ordinateur principal un système Windows, Mac (ou 'Windows on a Mac??') ou autre (tel Linux).»)

a { ordinateur principal ne permet pas de compter les double-boot ou machines virtuelles } + b { étudiant de première année, donc n'ayant que peu d'expérience } == c { il n'y a rien à conclure ,) }

je m'en fou d'avoir des feedbacks sur les licences et le code, je suis intéresse par des feedbacks sur le jeu.

Si tu annonces clairement la licence au début, tu auras plus de feedbacks sur le jeu ,-)

... les débats sur les licences libres (et la qualité du code ?) ne peuvent heureusement pas être évitées sur ce site. Il faut s'y faire ...

C'est aussi pourquoi la description est laconique.

Ce n'était pas une accusation. Un résumé bref en une phrase, c'est très bien et ça remplit parfaitement son rôle !

Ça ne me fait jamais plaisir de dénigrer le travail de quelqu'un d'autre :(

Tu proposes une publicité pour un p'tit jeu fait maison histoire de se détendre. Le résumé tient en une phrase et il n'y a malheureusement pas d'autre information que cet ÉNORME troll sur le moment "opportun" d'ouvrir le code.

Bon, c'est pas grave, c'est les vacances et le ciel est bleu. Mais tu aurais pu au moins :
1) indiquer la licence que tu penses utiliser par la suite;
2) à défaut de mettre une tarball à disposition, demander des conseils sur une forge-logicielle adaptée à ton projet;
3) ouvrir le débat sur autre chose. Je sais pas moi, "qu'est-ce que vous pensez des technologies employées ?, de la prise en main ? de la difficulté ?, ... "

Pas de code, pas de chocolat !

Pseudo-corollaire :
Pas de licence, pas de ... trolls *BSD/GPL !

Je viens de vérifier, mais sur Fedora 13 PackageKit est déjà par défaut.

//mode les goûts et les couleurs
En fait, je trouve l'interface très "gnomesque" : ergonomie simplifiée réduite au strict minimum vital. On tape le nom de l'application qu'on cherche dans l'unique champ de texte, "recherche" ... les résultats s'affichent, on coche et on appuie sur "valider".

Et jusqu'à présent, ça me suffit amplement. (comprendre "quand y'a un pépin, je repasse en ligne de commande")
///mode

Bref :
Par défaut il affiche la description du logiciel et le nom en gris clair illisible en tout petit au dessous.
Sûrement un problème de thème GTK+2. Aucun souci ici.

Impossible de faire une recherche par version de logiciel
Tu retiens plus facilement les 36 chiffres de versions que le nom de ton application ? Moi non ! Lorsque je cherche un paquet, je rentre son nom, le paquet est ensuite affiché en double, triple, etc. si plusieurs versions sont disponibles. Libre à toi de cocher une version différente pour la ré-installer.

Impossible de savoir quels logiciels sont présents dans un dépôt particulier

Bon oki, ça ne fonctionne pas pour ce cas là.

impossible de savoir l'état des paquets
Euh ... si. L'icône sous Fedora est clairement différent entre les paquets installés ou non. Sans compter la petite case à cocher sur le côté. Il existe même des filtres "n'afficher que les paquets déjà installés", "que les paquets non-installés", ...

Il refuse de dés-installer un paquet qui rentre en conflit, en l'occurrence plasma-widget-networkmanagement en conflit avec networkmanagement-kde.

J'ai parfois le même souci sous aptitude via SSH/ncurse. Certains spinningo-imbroglios de Debian causent des conflits de dépendances à priori insolvables. De la à dire que c'est la faute d'aptitude et non la mienne pour avoir voulu faire mon malin en croisant les dépôts stable / unstable / experimental, il y a un pas que je ne franchirais pas.

Oui, la grosse différence actuellement entre yum et apt-get, c'est que yum va automatiquement chercher à mettre à jour sa base de données via internet alors qu'apt-get vous forcera à le faire manuellement avec un `apt-get update`.

Conséquence directe pour l'utilisateur : le premier appel à yum est lent, puisqu'il faut se farcir le délai de connexion à chaque dépôt.

Parce qu'avec CGI, même pas besoin d'ouvrir un socket unix ou TCP pour communiquer avec le monde, il suffit de savoir lire sur stdin et écrire sur stdout. (... même si j'ai quand même un doute sur la gestion des sessions et des cookies, quelqu'un pourrait confirmer ?)

Ce qui m'amène à la conclusion suivante : choisit le premier langage qui te plaît.Tu trouveras toujours trois barbus excentriques pour te créer les sous-couches FastCGI/socket/HTTP/XML/JSON nécessaires à la "programmation web".

Et si tu cherches à apprendre un nouveau langage juste pour le bonheur de changer d'herbage, il ne faut pas avoir peur de tâtonner. Ça fait partie de l'expérience. Reviens ici (ou ailleurs) et pose des questions si certains aspects te semblent étrangers. Au pire tu pourras toujours changer d'avis et te lancer dans l'apprentissage d'un autre langage.

Cela dit, ma préférence va actuellement à Haskell, parce que :
- c'est un langage fonctionnel, contrairement au C, Java, Python et tout la clique
- je préfère sa syntaxe à celle du lisp (trop de parenthèses)
- la communauté est très active
- c'est une langage compilé, relativement performant (à peu près comme Java et bien mieux que Ruby ou Python)
- chaque jour je découvre des choses bizarres et amusantes (fermetures, functor, monades, arrows, etc.)

Cela dit la courbe d'apprentissage est assez sévère et si tu cherches un emploi, ce n'est pas la bonne option :)

(et pour d'autres avis, voir aussi les commentaires de ce journal: http://linuxfr.org/~marahi/29852.html )

C'est joli la liberté mais ce n'est pas une raison pour produire des services web techniquement défaillants. J'ai cité Opera Unite car c'est l'exemple le plus connu et dont les objectifs sont similaires à own[K]loud : l'accès à distance à des données utilisateur décentralisées.

Maintenant si tu veux des exemples libres qui fonctionnent, il y a(vait?) Ekiga, qui propose un serveur STUN pour contourner les limitations des NATs (bien que je ne sache pas si une solution identique soit possible dans ce cas). On peut aussi très bien imaginer d'intégrer le serveur Apache dans KDE (MySQL y étant déjà) et de gérer automatiquement les redirections NAT via upnp comme certaines consoles de salon ou certains logiciels bit-torrents le font déjà.

Bref, en développant plus le concept, on pourrait mettre tout le monde d'accord : les intégristes barbus comme la famille Michu.

L'installation d'ownCloud est relativement facile, il fonctionne simplement avec PHP sur un serveur web (donc un Apache avec base de donnée vite installés suffit). C'est un jeune projet qui pourrait devenir intéressant.

Mme Michu + serveur Apache = couic

Le truc simple qui marche actuellement, c'est Opera Unite. Mais pour ça il faut un serveur centralisé pour au minimum rediriger les requêtes et contourner ainsi les NAT de la MICHUbox.

Oui, on est d'accord. Mais ce qui m'a agacé c'est la tournure de la discussion qui est trop vite partie sur "real men use <ASM, C, Java, whatever>". La discussion originale mentionnait quelqu'un souhaitant se remettre, doucement, à la programmation. Il ne me semblait pas trop logique de parler de ses "sujets avancés". (un pointeur de pointeur de pointeur restant toujours un sujet épineux pour moi ,-)

La programmation va devenir, selon moi, un passage obligé de la plupart des sciences appliquées. Autant apprendre aux étudiants à correctement utiliser les outils à leur disposition.

Je l'espère aussi. Reste plus qu'à trouver des outils libres et des méthodes de formation pour convaincre les gens que la programmation n'est pas une prise de tête mais quelque chose leur permettant d'aller boire un café pendant que leur ordinateur travaille à leur place.

... histoire d'éviter de se retrouver avec une formation en info apparaissant toujours comme la 3ème roue du carrosse où, après une semaine de formation accélérée à C++, les étudiants sont lâchés sur des programmes style fem++ et doivent comprendre eux-même la signification de messages d'erreurs complètement cryptiques. Cela dit, peut-être qu'en remplaçant C++ par FORTRAN, on arriverait à diminuer le nombre de migraines, ou pas ...

Le C pour la programmation système, OK

Mais Python, Perl, Ruby, Haskell et autres sont bien la preuve qu'on peut développer des programmes plus ou moins simple sans forcément passer par la case "gestion de pointeurs et allocation de la mémoire".

J'ai rencontré beaucoup de personnes qui ne sont pas vouées à devenir contributeurs au noyau Linux et qui néanmoins doivent développer des programmes pour leur travail (genre des biologistes effectuant des traitements statistiques ou des mécaniciens sur des calculs de structure -- même raisonnement pour les sysadmins et développeurs web). Et pour ceux ayant subi l'infâme "introduction à l'informatique via C", le terme informatique avait une forte tendance à être synonyme de :
- perte de temps : passer des heures à rédiger du code qui ne compilera même pas
- complexité : pourquoi tant de fonctions pour entrer des données ? getc, getchar, fgetc, fgets, ...
- incompréhension : le fameux "segfault", qui nous laisse dans l'embarras sans aucune autre explication
- inutilité : 1 mois de travail sur un projet pour afficher seulement trois lignes de texte et deux triangles à l'écran

... et après on s'étonne qu'en fin de formation, tout le monde préférait Excel/Access à gcc :o

Oh ! [déclic neuronal/]

Je ne connaissais pas l'histoire des deux tirets de soulignement '__'. Après tests, il apparaît que seuls les attributs commençant par '__' et ne se terminant pas par '__' sont verrouillés. … histoire de rester consistant lorsqu'on décide de bidouiller __dict__ ou autre __class__.

C/C++ fortement typé ? Non je ne pense pas.
Sinon d'une manière générale, je pense que coder avec un langage "strict" ou déclaratif à l'extrême dans tous les cas de figure est contre-productif, et ce genre de langage devrait être utilisé que ans des cas particuliers.

Hum, le problème des langages typés forts ou faibles est un troll sans fin. De même concernant les autres "aides" à la programmation plus ou moins directive. :)

Chacun ses préférences, la mienne consiste à écrire un programme ainsi : le problème initial, une feuille et un crayon de bois, cribouillages, cribouillages, puis rédaction sur ordinateur et enfin le compilateur ou la suite de tests qui sert de filet de protection en m'aidant à vérifier et à gommer mes étourderies. Je ne cherche pas un truc extrêmement typé comme l'Ada (c'est comme du VHDL ça ?), juste le minimum syndical disponible avec le C++ qui m'empêchera de confondre un string avec un tableau d'entiers.

Certainement un défaut dû à ma formation universitaire et à ses méchants modules concernant l'UML, hihi. Ou alors cela vient de mon inexpérience (professionnelle) en programmation : j'ai bien plus d'aisance à m'exprimer à travers une feuille de papier qu'à travers une ligne de code.