Il est vrai que E16.6 est largement dépassé par la nouvelle version (E16.7.1). Ça n'est malheureusement pas encore disponible dans la debian (because oubli ? because freeze de Sarge ? Si c'est le cas c'est dommage : Sarge va se taper E16.6 qui n'a plus grand chose à voir avec E16.7). Enfin, j'ai fabriqué un paquet de E16.7 disponible là : http://j.portalier.free.fr/(...)
Sinon pour être tout à fait à jour il suffit de récupérer le CVS et de recompiler le paquet (le rép. debian est dispo ds le cvs).
Sinon c'est étrange ce bug. Je faisais tourner E16.6 sur un 300Mhz / 32Mo sans aucun problème...
J'avoue largement préférer la syntaxe StructuredText qui est assez facile à étendre légèrement pour ajouter quelques petites choses (comme les images).
Perso je préfère avoir une syntaxe du genre "ceci est un lien":htp://unlien au milieu de mon texte que devoir chercher à coups de Alt Gr un truc du genre [ceci est un lien|htp://unlien] pour en ajouter un... Idem je préfère utiliser "il devrait y avoir une image ici":img:htp://url/image.png plutôt que ((il devrait y avoir une image ici|htp://urlimage.png))... Idem pour le *texte en italique* je préfère les étoiles aux single quote. Ça se remarque mieux dans le texte...
( nota: j'use de htp et non pas http car sinon le code de DLFP me transofrme ça en lien ^^ )
Ça n'est peut-être qu'une affaire de goût, mais j'avoue trouver la syntaxe StructuredText plus claire, plus simple et plus agréable à utiliser à la longue.
Sinon j'ai une classe PHP StructuredText en cours de dév. (avec transformations ST->XHTML et inversement). Mais pas encore de "release" prévue pour le moment.
Le système de développement par « component », ou « composants » en français, est de mettre en place différentes composantes créant ensemble une distribution. Au lieu d'avoir un développement par paquets séparés les uns des autres et architecturés dans une suite de unstable/testing/stable (pour reprendre le schéma Debian par exemple).
Là on se retrouve avec des composants. À noter que FireFox n'est PAS un composant, mais un simple paquet, car il ne représente qu'une seule application. Par contre GNOME est un composant. Tout comme ce qu'on surnomme LAMP (Linux Apache MySQL PHP).
Ce qui est intéressant, c'est que chaque composant garde une certaine indépendance par rapport aux autres composants. Ainsi le composant GNOME peut contenir différentes branches : 2.4, 2.6, 2.8. 2.4 peut être considéré comme rendu obsolète par la 2.6, donc on peut placer la branche 2.6 comme étant stable et testée. Contrairement à la branche 2.8 qui elle est encore peu testée et dont on ne sait si elle est au moins aussi stable que la précédente. Au moment de créer une distrib ou de faire un snapshot stable, on prendra donc GNOME 2.6 et non 2.8. Tout en pouvant, et ce sans aucune difficulté, continuer le développement des paquets de GNOME 2.8, tout en continuant d'améliorer les paquets de GNOME 2.6. Etc.
À noter que pour fonctionner le composant GNOME à effectivement besoin du composant XFree86 ou du composant X.org. Mais ceci n'intervient pas dans son développement. Et finalement que je choisisse GNOME 2.6 ou GNOME 2.8, je me moque de savoir quelle version ou quel serveur X il va y avoir derrière. Il en faut un, c'est tout.
Cest là que la notion de composant est vraiment intéressante. Car c'est là que va bloquer (bêtement j'en convient) le processus de développement classique de la Debian (unstable/testing/stable). Car si un paquet important du système de base vient à être totalement buggué et instable, c'est tout ce qui gravite autour qui morfle, et le cycle reste bloqué (cf. les longues périodes de non maj automatiques de Sarge qd la glibc ou gcc sont cassés ds Sid). Dans la version par composant on s'en moque, car le système ne tourne pas autour de cette version cassée, mais sous la version du composant qui va bien.
Nota: le but (aussi) de la Progeny Debian est d'améliorer les paquets de la Debian, afin que Sarge (par exemple) soit encore meilleure. En la rendant compatible LSB 2.0 par exemple. De plus la Progeny Debian n'est finalement pas autre chose qu'une Debian. Mais architecturée et pensée différemment (pas qu'une stabilité des paquets, mais aussi une expérience utilisateur et une configuration générale déjà paramétrée).
Ce n'est pas en français, mais en anglais. C'est disponible dans un paquet de formats, mais je ne sais pas trop sil y a le ebook (le PalmOS pdb ça va ?), mais en tout cas il paraît que c super top come bouquin de SF. En tout cas c'est librement téléchargeable sur le net.
Ah oui, ça s'appelle Down and Out in the Magic Kingdom et c'est écrit par Cory Doctorow. À noter que d'autres nouvelles sont disponibles au téléchargement sur son site.
Je trouve qu'on peut comparer des distributions, et au contraire il est intéressant de le faire. Mais la dernière chose à faire est de prendre un ensemble de contraintes et de vouloir que chaque distrib réponde à ces contraintes. Ce que fait ici l'auteur de ce « test. »
Pour comparer des distributions, il vaut mieux d'abord se renseigner et savoir ce qu'elle vise, par qui et comment c'est développé, les choix stratégiques, etc.
Dans le cas de la Debian, on se rend très vite compte qu'il n'y a pas d'impératifs commerciaux ou public visé en particulier. Pas de patron ou groupement de marketeux qui tranchent les décisions quand au développement des paquets et surtout sur les choix du comportement et de la configuration par défauts de ceux ci.
Comme dit dans un commentaire plus haut : Debian c'est du brut de chez brut. La seule volonté des développeurs c'est d'avoir des paquets le plus stable possible. La configuration de base ? Elle est laissée aux désiratas particulier de chaque utilisateur. Personne n'est là pour changer le comportement par défaut des logiciels, desktop, etc. La configuration debconf doit toujours être des plus minimales.
Certains n'aiment pas cette idée, d'autres adorent. Moi je suis un peu entre les deux et je pense que de temps en temps certaines configurations par défaut pourraient être améliorées pour avoir une meilleur interopérabilité de fond et un fonctionnement plus simple. Le tout sans toujours avoir besoin d'aller bidouiller de la configuration (genre libgphoto2 et hotplug...)
Debian n'est pas une distribution développée spécifiquement dans un but précis (au contraire de la Fedora par exemple qui est hyper orienté Desktop). Et elle développé uniquement par des bénévoles, dans le plus pur esprit du « Libre. »
En fait, en lisant ce "test" je me dis que recherche son auteur, ça doit être une Progeny Debian : un seul CD de binaire, une orientation spécifiée (destop), etc.
Nota: oui, par défaut Debian ne fourni aucun utilitaire de configuration de son réseau en mode graphique. On peut trouver cela idiot, sauf que Debian ne fait pas de concessions ni de choix à la place de son utilisateur. Si on a du Gnome, le plus simple et efficace c'est d'utiliser gnome-system-tools. Si on a autre chose et bien on peut choisir d'utiliser autre chose. Debian ne conseille rien. Le conseil d'utiliser gnome-system-tools vient d'une doc Progeny d'ailleurs, et que je sâche : Progeny ce n'est pas Debian ! Progeny c'est une dérivation basée sur la Debian et qui est pro Gnome. Résultat il est tout à fait normal qu'ils conseillent d'utiliser gnome-system-tools et pas autre chose.
Vive PyGTK FAQ ! Moi ça me résoud presque tout le temps mes problèmes. Ensuite, il suffit de naviguer dans les docs de PyGTK. Le tutoriel est toujours pratique, mais surtout la référence donne accès à tout ce qu'il faut savoir.
L'une d'entres elles consiste à faire croire à l'utilisateur que GTK tourne toujours en le forçant à effectuer les tâches qu'il a en stock... Ça peut être pratique, mais c'est pas du threading. Généralement cette méthode est pratique pour mettre à jour des informations dans les fenêtres GTK quand on est dans un callback un peu (beaucoup) très long.
Sinon, on peut aussi initialiser le système de thread pour qu'il soit plus GTK aware (et inversement). Ça se passe au moment de l'initialisation de GTK. Au lieu d'utiliser seulement gtk.main() pour lancer la loop principale, on lance le mode threads avant et on le quitte après. C'est pas encore tout à fait le top, mais apparemment ça a l'air de marcher dans mes applis...
Voici une correction du code python qui permet de vraiment faire le calcul pour savoir si un nombre est, ou non, premier. La différence entre du code optimisé avec psyco et sans cette optimisation est flagrante dans ce genre d'exemple. Mais bon, c'est aussi que c'est juste dans ce genre de fonctions appellées un nombre indéfinissables de fois que psyco excelle.
#! /usr/bin/env python
from time import time
#import psyco
#psyco.full()
MAX=10000
def is_premier( nombre ):
for i in range( 2, nombre/2 ):
if nombre % i == 0: return 0
# print "%d est un nombre premier" % nombre
return 1
start = time()
for n in range( 0, MAX ): is_premier( n )
end = time()
print "tps unitaire: %fs" % ( ( end - start ) / MAX )
print "total: %.03fs" % ( end - start )
Nota: la correction consiste à ne pas tester la division par 1, car sinon le modulo est toujours égal à zéro ... donc le chiffre quel qu'il soit est détecté comme n'étant pas premier. Normal tout nombre est divisible par 1 et par lui même... Même les nombres premiers ^^ À noter aussi que ce genre de fonction n'est pas tip top pour effectuer des benchs, car plus le nombre MAX sera grand plus la fonction sera longue à appeller (à cause du range)... Résultat il faut obligatoirement utiliser la mm valeur MAX quelque soit le langage utilisé pour faire des benchs. D'ailleurs, avec un MAX de 10000, j'obtient 0.016ms par appel à is_premier() en utilisant psyco et 0.296ms par appel sans l'utiliser. No comment.
Tout à fait d'accord. Il serait mieux de faire la comparaison de temps utilisé directement dans le programme.
- Regarder l'heure qu'il est (debut)
- Lancer is_premier() sur n nombres, avec n un nombre suffisamment grand.
- Re-regarder l'heure qu'il est (fin)
- Faire la différence entre debut et fin et diviser le tout par n
Hop, on a le temps de calcul moyen pour la recherche d'un nombre premier (avec les temps d'appel de fct°, de passage de paramètres, etc). Et ce sans passer par la phase de précompilation, de compilation JIT, de lancement de l'application, etc. Là, le bench serait plus intéressant et réaliste.
D'ailleurs j'aimerai bien savoir ce que ça donne...
C'est assez rare les warnings ou les bugs à cause de psyco. Il y en a cependant (même si ça marche toujours très bien) dans la conversion de charsets.
Sinon, j'ajoute encore un drawback : le programme devient relativement long à démarrer (ben oui, faut compiler). Surtout avec full() qui compile tout et pas en fonction des besoins. Dans mes applications, j'utilise surtout profile() (comme c'est recommandé), et qui ne compile que ce qu'il est vraiment nécessaire de compiler.
J'ajoute un avantage : la possibilité de définir les fonctions à compiler, ou à partir de quel niveau compiler une fct°, etc.
En effet, il te manque un package, et un simple « apt-cache search hpijs » auraît pu te mettre la puce à l'oreille ;) Mais j'avoue que foomatic peut paraître bien étrange (d'ailleurs il l'est).
Son nom : « foomatic-db-hpijs », ça devrait t'installer foomatic et donc tout ce qu'il faut pour facilement paramétrer ton imprimante (installer une HP est bidon une fois tous les paquets installés).
Je te conseille aussi « foomatic-filters-ppds » qui devrait installer toutes les définitions d'imprimantes nécessaires pour juste avoir à choisir son imprimante dans une liste, et non s'embêter à chercher le bon PPD sur http://linuxprinting.org/(...) (quoique si elle est très récente, elle ne sera peut-être pas dans la liste).
Je te conseille sinon de choisir le driver « hpijs » tout court au moment du choix de l'imprimante, et non « gimp-print-hpijs » ou autre.
Ensuite moi j'utilise « gnome-cups-center » un très bon petit logiciel fort sympathique pour changer d'imprimante, modifier les paramètres, etc. Faut juste avoir le mot de passe root pour ajouter ou supprimer une imprimante, sinon ṡi c'est pr chger la qualité d'impression par exemple: pas besoin.
> Sylpheed-Claws est un client mail qui déchire ;-)
Oui, et pourtant je l'ai abandonné. La version GTK1 est radicalement moche, et la version GTK2 trop buggé pour prendre le temps de faire des bugs reports. Apparemment la version GTK2 n'est pas prévue pour fonctionner autrement qu'en locale C.
Ensuite, il faut bien le dire : les menus sont tout sauf intuitifs. C'est le gros bordel là dedans. Les options sont découpées de façon aléatoires dans plein de menus. On s'y perdre au moindre coup d'½il. Même après des mois d'utilisation quotidienne on cherche encore pendant une demi-heure des fois une bête option qui est dans un menu auquel on n'aurait pas pensé... Sans parler de la fenêtre pour créer/modifier les filtres... c'est limite incompréhensible et même après des mois d'utilisation on fini toujours par se tromper. C'est lourd, très lourd.
Un bon coup de nettoyage dans les menus et fenêtres d'options, filtres, etc. ferait le plus grand bien à Sylpheed (Claws ou Vanilla). Une application des GNOME HIG 2.0 serait tout aussi la bienvenue...
Mais force est d'avouer que c'est le seul logiciel d'emails qui soit efficace sans être d'une lourdeur infernale. Car evolution c'est bien gentil, mais c une véritable uzine à gaz qui fait tout ce qu'on ne lui demande pas dans une utilisation courante d'un logiciel d'emails. Balsa est pas mal et plutôt joli. Notamment son interface. Mais il a des trucs bizarres un peu partout... Un héritage de conception étrange qui pose problème.
En fait, n'étant satisfait par aucun client email actuel, je jette l'éponge à essayer d'en trouver un, et j'ai commencé il y a quelques à me faire le mien. En Python+GTK2+psyco avec une base locale en SQLITE, ce qui devrait m'offrir quelques petites astuces sympa. C'est bien, je dév. tout ça assez vite (merci le python et toutes ses libs de base) et j'essaye de respecter la simplicité d'utilisation générale en essayant de suivre la doctrine GNOME (sans pour autant reposer sur ses libs). Bien entendu ça sera du GPL ^^
Compiler le CVS de e17 ça veut dire "simplement" compiler les EFL : Enlightenment Foundation Libraries. Bref, uniquement les libs de base au fondement de tout le futur e17. Car e17 n'existe pas en tant que tel. Néanmoins e16 (version CVS) est déjà d'un très bon niveau et les mises à jour récentes le rende très très bon.
Néanmoins on peut aussi compiler quelques applications bien sympathiques, tel entrance, engage (mm si celle-ci aurait besoin d'un redesign complet de sa configuration) ou encore entice et autres equate. Bref, tout plein de logiciels bien sympa.
Je conseille cependant de compiler d'abord la prerelease des libs EFL (incomplètes certes, mais considérées stables), et ensuite d'aller chopper les bouts manquants dans le CVS. Nota: faire gaffe un API breakage à eu lieu dans ewl il y a quelques jours, et beaucoup de code n'ont pas encore été patchés (notamment entrance). J'ai aussi eu un bug avec imlib2 1.1.1 : elle me cassait complètement mon E16. Mais une compilation de imlib2 1.1.1cvs m'a tout réparé.
À noter que je suis tombé sur un bug trange avec libtool en voulant compiler le CVS de e. J'ai néanmoins réussi à le traquer (gniark gniark). Le problème qu'il me posait c'est qu'il ne voulait pas, mais alors vraiment pas me compiler de libs dynamiques (les .so). Rien à faire. Que des statiques (ce qui pose problème pour la gestion des plugins bien entendu et qui fout par terre tout e). La solution est d'éditer le fichier « configure.in » et de virer toute occurence à « AM_SHARED_TOOL » de relancer autogen.sh et hop, la compilation nous génère de belles lib dynamiques. Allez donc comprendre : on force la compilation de lib dyn et il ne veut pas le faire. On laisse faire le comportement par défaut et il le fait... Toujours pas compris mais au moins ça marche.
Et pis pour ceux qui ont la flemme de compiler e17 (je les comprends, c'est pas de toute repos), mais qui veulent quand même essayer ces fameuses applications (et là je les comprends encore plus), je suis en train d'uploader les paquets debian que je me suis fait dans mon repository : http://j.portalier.free.fr(...) . Vous y trouverez aussi E 16.7.1cvs, qui corrige pas mal de bugs (importants) de la version considérée stable sortie il y a peu (E 16.7).
Le coup de développement ne devais pas être si grand, mais le marché si vide que ça ne vallait pas le copu de passer du temps à porter le truc et à faire tous les tests qu'il fallait. De plus ça aurait retardé la sortie du produit, ou alors ils auraient dû faire une version spécifique GNU/Linux qui ne se serait pas suffisamment vendue. Résultat ils auraient certainement eu une marge déficitaire sur le produit.
En effet : ce n'est qu'un problème de Marketing.
Ou alors: ils ne connaissaient même pas GNU/Linux, ce qui ne m'étonnerai guère...
Aujourd'hui apparamment ils connaissent et ont l'air de flairer un bon gros marché potentiel... Ou alors la société qui travaille avec eux a bien fait son boulot en indiquant qu'en choisissant leur solution, le portage était simple et efficace, que Linux était en voix d'un développement durable et attirait de plus en plus le public.
Bon j'espère juste que ce ne sera pas un engouement limité à maintenant tout de suite et qu'il ne se perdra pas. Mais vu que le développement des Desktops basés partent dans de bonnes directions (merci freedesktop.org) ça devrait aller.
L'appel du gouvernement sur les logiciels libres aura peut-être eu un impact aussi. Si les bibliothèques et autres institutions nationales passent sous GNU/Linux, il serait bien que les logiciels le puissent aussi. C'est peut-être ça que vise Hachette - et les autres, tel Universalis - en amont. Un passage progressif et futur à GNU/Linux dans beaucoup de foyers (notamment étudiants), dans les bibliothèques, etc.
J'utilise déjà tous ses dictionnaires. Ils doivent me servent 30% du temps seulement (c'est déjà ça, vous me direz), pour plusieurs raisons :
1- la plupart du temps il n'y a que la traduction du mot comme ça : mot anglais = liste de mots français. C'est bien c'est pratique, c'est minimal. Tellement qu'il manque franchement tout ce qu'on trouve dans un vrai dictionnaire. Seul le wiktionnary me semble intéressant sur ce point et capable de concurrencer les vrais dictionnaires de langues.
2- le nombre de mots et de définitions connues. Je trouve presque tout le temps les mots et expressions que je cherche dans mon bon vieux dico (qui commence à avoir quelques années pourtant). Alors que tous ses dicos libres sont, il faut bien le reconnaître, très vides... Et là le wiktionnary par exemple a encore un long chemin à parcourir avant d'y arriver !
Seul dict.org est un vrai bon dictionnaire. Mais unilangue. Et je n'y ai d'ailleurs trouvé que des dictionnaires anglais. Freedict.org est intéressant mais se contente d'une trad. des définitions type mot=mots et les dictionnaires sont finalement assez vides. Quand on sait que le mots ne sont jamais traduisibles directement, mais que tout passe par le contexte, on se demande l'intérêt de ces dictionnaires. Il ne sert que pour celui qui connaît déjà le mot, mais a un trou de mémoire (dans ce cas c'est très efficace). Mais la traduction est avant tout affaire de sens (et il suffit de voir combien une traduction à la systrans est mauvaise (ridicule?) pour s'en rendre compte.
Pour le japonais, je ne saurais que conseiller "jmdict" (jpn/eng et eng/jpn). Il me donne toujours des résultats dans les deux sens. Seul problème : ce sont deux langues étrangères, donc on retombe toujours dans le mm problème de la trad. en français ...
Nota: je ne râle pas contre les solutions libres, je dis qu'elles ne sont pas adaptées, et que ce n'est pas anormal. Un dictionnaire est quelque chose de très lourd à mettre en place. D'autant plus qu'on pourrait être facilement tenté de simplement recopier son robert & collins par exemple... C'est pourquoi je suis tout à fait pour l'achat de solutions proprios, en attendant qe les solutions libres n'arrivent à un niveau acceptable.
J'utilise déjà stardict. Avec un maximum de dictionnaires. Le truc c'est que je n'ai pas trop de problèmes dans le vocabulaire anglais courant. Résultat la plupart de mes recherches ne me donnent aucun résultat en français... Ce qui n'est guère le résultat attendu. Par contre le dico en-ja et ja-en est impressionnant et répond presque tout le temps à toutes mes questions, mais bon...
Stardict est bien, mais les dictionnaires sont très limités en fin de compte. Je suis tout le tps obligé d'aller fouiller mon vrai dico réel, en papier.
Sinon je vois qu'il y a plein de références dan les posts en dessous. Je vais y jeter un coup d'½il.
La question tourne essentiellement de savoir si avoir E17 - qui est essentiellement un WM (window manager) fonctionnant directement sur XCB ne va pas poser problème avec les applications qui utilisent elles la Xlib. La question est légitime: est-ce que ça va pas tout casser nos belles applications sous X ?!
Rasterman en profite pour expliquer quelle est la place d'un WM sous X mis en rapport avec les applications qu'il "manage". En expliquant q'un WM ne se pose pas entre le serveur X et les applications, mais que le serveur X est central et que le WM cause avec X tout comme le font les applications.
Le problème ne se pose donc pas. Et ça se confirme si on y regarde d'un peu plus près. Car XCB - tout comme la Xlib - cause directement avec le protocole X11, donc directement avec le serveur XFree86. Au final XCB et Xlib font la même chose, mais de façon différente. XCB semblant d'ailleurs avoir une bien meilleure architecture générale que la Xlib. Et ça ne s'arrête pas qu'au mode asynchrone. Allez donc voir la page XCB sur freedesktop.org
Résultat : il n'y a aucune raison pour qu'une applications utilisant la Xlib ait des problèmes à cause que le WM lui il utilise XCB. C'est là toute la base de la discussion sur la ML de e. Moi en tout cas ça m'a bien éclairé sur ce qu'est vraiment XCB. À noter que Rasterman est semble vraiment entousiasmé par cette nouvelle lib ^^
Vala. L'explication est suffisamment claire ?
Ha! Y'a aussi une ébauche de discussion sur l'intérêt réel de XCB, notamment mis en rapport avec Xorg (ou xouvert). Pas vraiment de réponse donné cependant. Mais à ce que j'ai cru comprendre XCB est bénéfique pour tout serveur X, car cette lib vient en remplacement ou se pose en concurrence de la Xlib. Je pense donc que XCB peut parfaitement être intégré à un autre serveur X. Surtout lorsque ceux-ci ont la même base : XFree86.
Au final je pense que XCB devrait être bénéfique aussi à Xorg et xouvert. Miam d'avance ^^
Faut pas oublié la fct° qui tue tout : le dualhead. Sur une seule carte le tout sur AGP. Pratique: deux sorties, hop deux écrans, le tout avec les accélérations qui vont bien. Bon certes il faut le binaire "hal" qui n'est pas libre pour faire fonctionner X correctement avec, mais bon.
Mias il est vrai qu'en 3D ça commence à se faire vraiment très très vieux... idem pour la qualité en 2D, ces cartes commencent à se faire vieilles. Mais après il est dur de trouver des équivalents en dualhead :(
Moi ce qui me serait extrèmement utile ce serait un bon dictionnaire anglais-français et français-anglais disponible sur cdrom (ou dvdrom), et facilement exploitable sous gnu/linux... Parce que devoir fouiller un gros dico papier c'est pas des plus pratique quand on veut faire de la trad. et qu'on tombe sur des passages pleins de mots inconnus .. alors qu'une simple recherche sur une bdd c'est bien plus facile ^^
Enfin, si les encyclopédies commencent à arriver pour notre manchot préféré et de façon intelligente (xul), on peut se dire que les dicos vont suivre la marche. J'aimerai bien voir rappliquer le robert & collins version 2 tomes en version numérique exploitable sous gnu/linux...
Nota: si quelqu'un a de très bon dicos d'anglais-français (et inversement) libres qu'il n'hésite pas à me le faire savoir ^^ Perso je n'ai pas trouvé grand chose. Mon dico le plus complet c'est un anglais-japonais... ce qui n'est guère des plus pratiques, vu que je baragouine à peine un peu de jpn ^^
Auto réponse : en fait j'avais pas vu que libgnomedb était elle-même une surcouche à libgda qui gère les accès aux bases de données. Il suffit d'installer le backend MySQL à libgda et tout devrait marcher.
Sauf que ça marche pas. J'arrive bien à définir des accès à des BDD, mais mergeant ne me laisse pas les sélectionner lorsque je veux me connecter. La liste des BDD définies - reste désespéremment vide.
D'ailleurs pourquoi il ne va pas chercher les bases de données disponibles tout seul comme un grand comme le fait PHP My Admin ? Il suffirait de sélectionner un backend (XML, MySQL, etc.) ainsi qu'un login et hop : il nous donne la liste des BDD auxquelles on a accès et on peut s'y connecter.
C'est idiot de devoir définir les BDD disponibles...
Ou alors y'a un truc que j'ai pas compris et c'est franchement pas user-friendly (un comble pour une appli GNOME 2).
Y'a moyen d'avoir un backend MySQL (ou PGSQL) quand on utilise libgnomedb ? Parce que par défaut il n'y a que le backend XML et je n'arrive pas à trouver d'autres backend, ce qui limite franchement l'utilisation de Mergeant du même coup...
Exact, il n'y a aucune possibilité de pouvoir prendre le contrôle d'une session X déjà ouverte sur un poste distant. VNS permet seulement de lancer une session X "virtuelle", uniquement accessible via le réseau (et qu'on peut utiliser sur des postes non X).
Mais est-il vraiment nécessaire de devoir prendre le contrôle d'un PC à distance ? L'ouverture d'une session X distante permet largement d'installer des logiciels. Une simple connexion SSH devrait être largement suffisante d'ailleurs, sachant qu'il existe des logiciels permettant de contrôler simultanément plusieurs xterm en même temps. Ceci permet de mettre à jour tout un parc d'ordinateur d'une seule commande centrale, tout en voyant les résultats poste par poste.
Perso je ne vois pas le besoin nécessaire à devoir prendre le contrôle d'une session distante (à part installer un trou dans la sécurité des postes). Sauf si c'est pour pouvoir dépanner une session d'un utilisateur sans bouger ses fesses de son bureau ^^
Car dans ton exemple tu prends 'tmp_name' comme étant un répertoire dans le lequel tu vas trouver 'name', alors que 'tmp_name' est déjà le nom du fichier temporaire, avec tout son chemin. Et oui ç a un nom bizarre du style "/tmp/php??????".
Ce qui me manque ce sont les grades (moines, dieu...)
Je suis tout à fait d'accord. C'est vrai que c'est amusant d'avoir un grade. Et encore plus lorsque les noms sont drôles ^^
Java a certes des qualités, mais putain qu'il est lent, en plus d'être propriétaire. Heuresement mono/.NET arrive pour nous sauver. J'espére que ce sera de base dans la Suse, seule distrib réellement pro (debian serait bien si elle était plus à jour, quand aux BSD, quand leur licence sera acceptable, on aura fait un grand pas en avant)...
Mouarf, concentré de trolls détecté. Bien vivaces en plus. Faire gaffe : reproduction en cours. D'ailleurs : ayant testé quelques applis Mono j'avoue être agréablement surpris : c'est loin d'être désagréable et lourd comme n'importe quelle application Java (mode graphique) sur un même système. J'aimerai bien voir une même application codée optimalement pour Java et pour Mono, histoire de voir la différence (réactivité, consommation cpu & mémoire, etc.)
J'ai découvert quelques artistes bien sympa sur magnatune. Les morceaux sont en MP3 128k (pour le ogg ou le FLAC faudra rémunérer les artistes). La licence de ces MP3 c'est la « creative commons non commercial share alike. »
Perso j'écoute beaucoup (et je vais acheter d'ailleurs tellemnt c'est bon)
- Beth Quist
- Cargo Cult
- Very Large Array
- Solace
Voilà déjà de bons artistes. Mais je suis loin d'avoir écouté tous les artistes de magnatune (je me réfrène aussi, sinon ça va me coûter cher au final: ben ouais, la musique de qualité et qu'on est pas obligé de payer, ben tout de suite ça donne envie de donner un peu d'argent... surtout quand c'est pas à de méchants raquetteurs).
XMMS est quelque peu « mort » ou du moins restera dans l'état actuel. Le but des dévs n'est pas de continuer son développement et de le laisser complètement limité. Au contraire XMMS2 s'ouvre vers quelque chose de bien plus intéressant : un démon avec lequel on peut facilement discuter via DBUS. Ça permet d'avoir autant de frontends qu'on veut : beaucoup largement plus mieux. Y'a par exemple un client (console), euphoria (E17), etc.
Après si tu veux seulement une avancée de XMMS vers GTK+2 et quelques trucs : http://beepmp.sf.net/(...)
Mais personnelement je pense que l'idée de XMMS2 est bien intéressante. Avoir un démon qui s'occupe de tout ce qui est playlist/lecture, etc et qui le fait superbement bien. Et ensuite des frontends (qu'on peut quitter sans que ça coupe la musique, pratique pour libérer de la mémoire) en veux-tu en voilà qui font chacun exactement ce qu'on leur demande de faire (un truc à la rythmbox qui gère votre collection de MP3 ou un bête truc tout simple où qu'on glisse ses fichiers audio dessus).
[^] # Re: Enlight 16.7
Posté par Julien Portalier . En réponse au message Enlightenment fait ramer Xfree?. Évalué à 2.
Sinon pour être tout à fait à jour il suffit de récupérer le CVS et de recompiler le paquet (le rép. debian est dispo ds le cvs).
Sinon c'est étrange ce bug. Je faisais tourner E16.6 sur un 300Mhz / 32Mo sans aucun problème...
# StructuredText
Posté par Julien Portalier . En réponse au message Mise en forme des commentaires. Évalué à 2.
Perso je préfère avoir une syntaxe du genre "ceci est un lien":htp://unlien au milieu de mon texte que devoir chercher à coups de Alt Gr un truc du genre [ceci est un lien|htp://unlien] pour en ajouter un... Idem je préfère utiliser "il devrait y avoir une image ici":img:htp://url/image.png plutôt que ((il devrait y avoir une image ici|htp://urlimage.png))... Idem pour le *texte en italique* je préfère les étoiles aux single quote. Ça se remarque mieux dans le texte...
( nota: j'use de htp et non pas http car sinon le code de DLFP me transofrme ça en lien ^^ )
Ça n'est peut-être qu'une affaire de goût, mais j'avoue trouver la syntaxe StructuredText plus claire, plus simple et plus agréable à utiliser à la longue.
Aller: une ch'tite liste de liens.
* http://dev.zope.org/Members/jim/StructuredTextWiki/StructuredTextRu(...)
* http://dev.zope.org/Members/jim/StructuredTextWiki/TextFormattingRu(...)
* http://zwiki.org/StructuredText(...)
* http://plone.org/documentation/howto/FrontPage/UsingStructuredText(...)
Sinon j'ai une classe PHP StructuredText en cours de dév. (avec transformations ST->XHTML et inversement). Mais pas encore de "release" prévue pour le moment.
[^] # Re: le principe ? (désolé)
Posté par Julien Portalier . En réponse au journal Progeny Debian 2.0 beta 2. Évalué à 3.
Là on se retrouve avec des composants. À noter que FireFox n'est PAS un composant, mais un simple paquet, car il ne représente qu'une seule application. Par contre GNOME est un composant. Tout comme ce qu'on surnomme LAMP (Linux Apache MySQL PHP).
Ce qui est intéressant, c'est que chaque composant garde une certaine indépendance par rapport aux autres composants. Ainsi le composant GNOME peut contenir différentes branches : 2.4, 2.6, 2.8. 2.4 peut être considéré comme rendu obsolète par la 2.6, donc on peut placer la branche 2.6 comme étant stable et testée. Contrairement à la branche 2.8 qui elle est encore peu testée et dont on ne sait si elle est au moins aussi stable que la précédente. Au moment de créer une distrib ou de faire un snapshot stable, on prendra donc GNOME 2.6 et non 2.8. Tout en pouvant, et ce sans aucune difficulté, continuer le développement des paquets de GNOME 2.8, tout en continuant d'améliorer les paquets de GNOME 2.6. Etc.
À noter que pour fonctionner le composant GNOME à effectivement besoin du composant XFree86 ou du composant X.org. Mais ceci n'intervient pas dans son développement. Et finalement que je choisisse GNOME 2.6 ou GNOME 2.8, je me moque de savoir quelle version ou quel serveur X il va y avoir derrière. Il en faut un, c'est tout.
Cest là que la notion de composant est vraiment intéressante. Car c'est là que va bloquer (bêtement j'en convient) le processus de développement classique de la Debian (unstable/testing/stable). Car si un paquet important du système de base vient à être totalement buggué et instable, c'est tout ce qui gravite autour qui morfle, et le cycle reste bloqué (cf. les longues périodes de non maj automatiques de Sarge qd la glibc ou gcc sont cassés ds Sid). Dans la version par composant on s'en moque, car le système ne tourne pas autour de cette version cassée, mais sous la version du composant qui va bien.
Nota: le but (aussi) de la Progeny Debian est d'améliorer les paquets de la Debian, afin que Sarge (par exemple) soit encore meilleure. En la rendant compatible LSB 2.0 par exemple. De plus la Progeny Debian n'est finalement pas autre chose qu'une Debian. Mais architecturée et pensée différemment (pas qu'une stabilité des paquets, mais aussi une expérience utilisateur et une configuration générale déjà paramétrée).
# Down & out in the magic kingdom
Posté par Julien Portalier . En réponse au journal SF, ebook.... Évalué à 3.
http://www.craphound.com/down/download.php(...)
Ah oui, ça s'appelle Down and Out in the Magic Kingdom et c'est écrit par Cory Doctorow. À noter que d'autres nouvelles sont disponibles au téléchargement sur son site.
[^] # Re: mon point de vue
Posté par Julien Portalier . En réponse au journal Debian : J'ai le coeur fendu par toi (long). Évalué à 4.
Pour comparer des distributions, il vaut mieux d'abord se renseigner et savoir ce qu'elle vise, par qui et comment c'est développé, les choix stratégiques, etc.
Dans le cas de la Debian, on se rend très vite compte qu'il n'y a pas d'impératifs commerciaux ou public visé en particulier. Pas de patron ou groupement de marketeux qui tranchent les décisions quand au développement des paquets et surtout sur les choix du comportement et de la configuration par défauts de ceux ci.
Comme dit dans un commentaire plus haut : Debian c'est du brut de chez brut. La seule volonté des développeurs c'est d'avoir des paquets le plus stable possible. La configuration de base ? Elle est laissée aux désiratas particulier de chaque utilisateur. Personne n'est là pour changer le comportement par défaut des logiciels, desktop, etc. La configuration debconf doit toujours être des plus minimales.
Certains n'aiment pas cette idée, d'autres adorent. Moi je suis un peu entre les deux et je pense que de temps en temps certaines configurations par défaut pourraient être améliorées pour avoir une meilleur interopérabilité de fond et un fonctionnement plus simple. Le tout sans toujours avoir besoin d'aller bidouiller de la configuration (genre libgphoto2 et hotplug...)
Debian n'est pas une distribution développée spécifiquement dans un but précis (au contraire de la Fedora par exemple qui est hyper orienté Desktop). Et elle développé uniquement par des bénévoles, dans le plus pur esprit du « Libre. »
En fait, en lisant ce "test" je me dis que recherche son auteur, ça doit être une Progeny Debian : un seul CD de binaire, une orientation spécifiée (destop), etc.
Nota: oui, par défaut Debian ne fourni aucun utilitaire de configuration de son réseau en mode graphique. On peut trouver cela idiot, sauf que Debian ne fait pas de concessions ni de choix à la place de son utilisateur. Si on a du Gnome, le plus simple et efficace c'est d'utiliser gnome-system-tools. Si on a autre chose et bien on peut choisir d'utiliser autre chose. Debian ne conseille rien. Le conseil d'utiliser gnome-system-tools vient d'une doc Progeny d'ailleurs, et que je sâche : Progeny ce n'est pas Debian ! Progeny c'est une dérivation basée sur la Debian et qui est pro Gnome. Résultat il est tout à fait normal qu'ils conseillent d'utiliser gnome-system-tools et pas autre chose.
Enfin bon, j'arrête ici ma diatribe.
[^] # Re: tuto pour gtk textwiew
Posté par Julien Portalier . En réponse au message Textview Python/Gtk. Évalué à 3.
FAQ: http://www.async.com.br/faq/pygtk/index.py?req=index(...)
Tutoriel: http://www.pygtk.org/pygtk2tutorial/index.html(...)
Référence: http://www.pygtk.org/pygtk2reference/index.html(...)
Pour le threading, c'est un peu délicat. Il y a plusieurs réponses dans la PyGTK FAQ, suivant les types de situations :
3.7 While my callback is executing, nothing is refreshed in the application windows! ( http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq03.(...) )
20. The GTK Mainloop and Threading
L'une d'entres elles consiste à faire croire à l'utilisateur que GTK tourne toujours en le forçant à effectuer les tâches qu'il a en stock... Ça peut être pratique, mais c'est pas du threading. Généralement cette méthode est pratique pour mettre à jour des informations dans les fenêtres GTK quand on est dans un callback un peu (beaucoup) très long.
Sinon, on peut aussi initialiser le système de thread pour qu'il soit plus GTK aware (et inversement). Ça se passe au moment de l'initialisation de GTK. Au lieu d'utiliser seulement gtk.main() pour lancer la loop principale, on lance le mode threads avant et on le quitte après. C'est pas encore tout à fait le top, mais apparemment ça a l'air de marcher dans mes applis...
gtk.gdk.threads_init()
gtk.gdk.threads_enter()
gtk.main()
gtk.gdk.threads_leave()
# Correction du code python
Posté par Julien Portalier . En réponse au message bench : pourquoi python serait lent ?. Évalué à 2.
[^] # Re: sources
Posté par Julien Portalier . En réponse au message bench : pourquoi python serait lent ?. Évalué à 2.
- Regarder l'heure qu'il est (debut)
- Lancer is_premier() sur n nombres, avec n un nombre suffisamment grand.
- Re-regarder l'heure qu'il est (fin)
- Faire la différence entre debut et fin et diviser le tout par n
Hop, on a le temps de calcul moyen pour la recherche d'un nombre premier (avec les temps d'appel de fct°, de passage de paramètres, etc). Et ce sans passer par la phase de précompilation, de compilation JIT, de lancement de l'application, etc. Là, le bench serait plus intéressant et réaliste.
D'ailleurs j'aimerai bien savoir ce que ça donne...
[^] # Re: A propos de Psyco
Posté par Julien Portalier . En réponse au message bench : pourquoi python serait lent ?. Évalué à 2.
Sinon, j'ajoute encore un drawback : le programme devient relativement long à démarrer (ben oui, faut compiler). Surtout avec full() qui compile tout et pas en fonction des besoins. Dans mes applications, j'utilise surtout profile() (comme c'est recommandé), et qui ne compile que ce qu'il est vraiment nécessaire de compiler.
J'ajoute un avantage : la possibilité de définir les fonctions à compiler, ou à partir de quel niveau compiler une fct°, etc.
[^] # Re: CUPS ?
Posté par Julien Portalier . En réponse au message installer une imprimante HP par la méthode debian. Évalué à 2.
Son nom : « foomatic-db-hpijs », ça devrait t'installer foomatic et donc tout ce qu'il faut pour facilement paramétrer ton imprimante (installer une HP est bidon une fois tous les paquets installés).
Je te conseille aussi « foomatic-filters-ppds » qui devrait installer toutes les définitions d'imprimantes nécessaires pour juste avoir à choisir son imprimante dans une liste, et non s'embêter à chercher le bon PPD sur http://linuxprinting.org/(...) (quoique si elle est très récente, elle ne sera peut-être pas dans la liste).
Je te conseille sinon de choisir le driver « hpijs » tout court au moment du choix de l'imprimante, et non « gimp-print-hpijs » ou autre.
Ensuite moi j'utilise « gnome-cups-center » un très bon petit logiciel fort sympathique pour changer d'imprimante, modifier les paramètres, etc. Faut juste avoir le mot de passe root pour ajouter ou supprimer une imprimante, sinon ṡi c'est pr chger la qualité d'impression par exemple: pas besoin.
[^] # Re: sylpheed-claws
Posté par Julien Portalier . En réponse au journal Sortie de Sylpheed-Claws 0.9.12a. Évalué à 3.
Oui, et pourtant je l'ai abandonné. La version GTK1 est radicalement moche, et la version GTK2 trop buggé pour prendre le temps de faire des bugs reports. Apparemment la version GTK2 n'est pas prévue pour fonctionner autrement qu'en locale C.
Ensuite, il faut bien le dire : les menus sont tout sauf intuitifs. C'est le gros bordel là dedans. Les options sont découpées de façon aléatoires dans plein de menus. On s'y perdre au moindre coup d'½il. Même après des mois d'utilisation quotidienne on cherche encore pendant une demi-heure des fois une bête option qui est dans un menu auquel on n'aurait pas pensé... Sans parler de la fenêtre pour créer/modifier les filtres... c'est limite incompréhensible et même après des mois d'utilisation on fini toujours par se tromper. C'est lourd, très lourd.
Un bon coup de nettoyage dans les menus et fenêtres d'options, filtres, etc. ferait le plus grand bien à Sylpheed (Claws ou Vanilla). Une application des GNOME HIG 2.0 serait tout aussi la bienvenue...
Mais force est d'avouer que c'est le seul logiciel d'emails qui soit efficace sans être d'une lourdeur infernale. Car evolution c'est bien gentil, mais c une véritable uzine à gaz qui fait tout ce qu'on ne lui demande pas dans une utilisation courante d'un logiciel d'emails. Balsa est pas mal et plutôt joli. Notamment son interface. Mais il a des trucs bizarres un peu partout... Un héritage de conception étrange qui pose problème.
En fait, n'étant satisfait par aucun client email actuel, je jette l'éponge à essayer d'en trouver un, et j'ai commencé il y a quelques à me faire le mien. En Python+GTK2+psyco avec une base locale en SQLITE, ce qui devrait m'offrir quelques petites astuces sympa. C'est bien, je dév. tout ça assez vite (merci le python et toutes ses libs de base) et j'essaye de respecter la simplicité d'utilisation générale en essayant de suivre la doctrine GNOME (sans pour autant reposer sur ses libs). Bien entendu ça sera du GPL ^^
# Compiler e17 ...
Posté par Julien Portalier . En réponse au message Tester le CVS d'E17 : un guide ?. Évalué à 2.
Néanmoins on peut aussi compiler quelques applications bien sympathiques, tel entrance, engage (mm si celle-ci aurait besoin d'un redesign complet de sa configuration) ou encore entice et autres equate. Bref, tout plein de logiciels bien sympa.
Pour compiler les EFL, rien de mieux que de consulter les notes CVS (notamment pour l'ordre de compilation) : http://enlightenment.org/pages/cvsnotes.html(...)
Je conseille cependant de compiler d'abord la prerelease des libs EFL (incomplètes certes, mais considérées stables), et ensuite d'aller chopper les bouts manquants dans le CVS. Nota: faire gaffe un API breakage à eu lieu dans ewl il y a quelques jours, et beaucoup de code n'ont pas encore été patchés (notamment entrance). J'ai aussi eu un bug avec imlib2 1.1.1 : elle me cassait complètement mon E16. Mais une compilation de imlib2 1.1.1cvs m'a tout réparé.
À noter que je suis tombé sur un bug trange avec libtool en voulant compiler le CVS de e. J'ai néanmoins réussi à le traquer (gniark gniark). Le problème qu'il me posait c'est qu'il ne voulait pas, mais alors vraiment pas me compiler de libs dynamiques (les .so). Rien à faire. Que des statiques (ce qui pose problème pour la gestion des plugins bien entendu et qui fout par terre tout e). La solution est d'éditer le fichier « configure.in » et de virer toute occurence à « AM_SHARED_TOOL » de relancer autogen.sh et hop, la compilation nous génère de belles lib dynamiques. Allez donc comprendre : on force la compilation de lib dyn et il ne veut pas le faire. On laisse faire le comportement par défaut et il le fait... Toujours pas compris mais au moins ça marche.
Et pis pour ceux qui ont la flemme de compiler e17 (je les comprends, c'est pas de toute repos), mais qui veulent quand même essayer ces fameuses applications (et là je les comprends encore plus), je suis en train d'uploader les paquets debian que je me suis fait dans mon repository : http://j.portalier.free.fr(...) . Vous y trouverez aussi E 16.7.1cvs, qui corrige pas mal de bugs (importants) de la version considérée stable sortie il y a peu (E 16.7).
[^] # Re: Ils auraient pu le faire avant : moué...
Posté par Julien Portalier . En réponse à la dépêche Encyclopédie Hachette Multimédia sous Linux. Évalué à 2.
En effet : ce n'est qu'un problème de Marketing.
Ou alors: ils ne connaissaient même pas GNU/Linux, ce qui ne m'étonnerai guère...
Aujourd'hui apparamment ils connaissent et ont l'air de flairer un bon gros marché potentiel... Ou alors la société qui travaille avec eux a bien fait son boulot en indiquant qu'en choisissant leur solution, le portage était simple et efficace, que Linux était en voix d'un développement durable et attirait de plus en plus le public.
Bon j'espère juste que ce ne sera pas un engouement limité à maintenant tout de suite et qu'il ne se perdra pas. Mais vu que le développement des Desktops basés partent dans de bonnes directions (merci freedesktop.org) ça devrait aller.
L'appel du gouvernement sur les logiciels libres aura peut-être eu un impact aussi. Si les bibliothèques et autres institutions nationales passent sous GNU/Linux, il serait bien que les logiciels le puissent aussi. C'est peut-être ça que vise Hachette - et les autres, tel Universalis - en amont. Un passage progressif et futur à GNU/Linux dans beaucoup de foyers (notamment étudiants), dans les bibliothèques, etc.
[^] # Re: À quand les dictionnaires de langue ?
Posté par Julien Portalier . En réponse à la dépêche Encyclopédie Hachette Multimédia sous Linux. Évalué à 2.
1- la plupart du temps il n'y a que la traduction du mot comme ça : mot anglais = liste de mots français. C'est bien c'est pratique, c'est minimal. Tellement qu'il manque franchement tout ce qu'on trouve dans un vrai dictionnaire. Seul le wiktionnary me semble intéressant sur ce point et capable de concurrencer les vrais dictionnaires de langues.
2- le nombre de mots et de définitions connues. Je trouve presque tout le temps les mots et expressions que je cherche dans mon bon vieux dico (qui commence à avoir quelques années pourtant). Alors que tous ses dicos libres sont, il faut bien le reconnaître, très vides... Et là le wiktionnary par exemple a encore un long chemin à parcourir avant d'y arriver !
Seul dict.org est un vrai bon dictionnaire. Mais unilangue. Et je n'y ai d'ailleurs trouvé que des dictionnaires anglais. Freedict.org est intéressant mais se contente d'une trad. des définitions type mot=mots et les dictionnaires sont finalement assez vides. Quand on sait que le mots ne sont jamais traduisibles directement, mais que tout passe par le contexte, on se demande l'intérêt de ces dictionnaires. Il ne sert que pour celui qui connaît déjà le mot, mais a un trou de mémoire (dans ce cas c'est très efficace). Mais la traduction est avant tout affaire de sens (et il suffit de voir combien une traduction à la systrans est mauvaise (ridicule?) pour s'en rendre compte.
Pour le japonais, je ne saurais que conseiller "jmdict" (jpn/eng et eng/jpn). Il me donne toujours des résultats dans les deux sens. Seul problème : ce sont deux langues étrangères, donc on retombe toujours dans le mm problème de la trad. en français ...
Nota: je ne râle pas contre les solutions libres, je dis qu'elles ne sont pas adaptées, et que ce n'est pas anormal. Un dictionnaire est quelque chose de très lourd à mettre en place. D'autant plus qu'on pourrait être facilement tenté de simplement recopier son robert & collins par exemple... C'est pourquoi je suis tout à fait pour l'achat de solutions proprios, en attendant qe les solutions libres n'arrivent à un niveau acceptable.
[^] # Re: À quand les dictionnaires de langue ?
Posté par Julien Portalier . En réponse à la dépêche Encyclopédie Hachette Multimédia sous Linux. Évalué à 3.
Stardict est bien, mais les dictionnaires sont très limités en fin de compte. Je suis tout le tps obligé d'aller fouiller mon vrai dico réel, en papier.
Sinon je vois qu'il y a plein de références dan les posts en dessous. Je vais y jeter un coup d'½il.
[^] # Re: XCB+E17
Posté par Julien Portalier . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 10.
Rasterman en profite pour expliquer quelle est la place d'un WM sous X mis en rapport avec les applications qu'il "manage". En expliquant q'un WM ne se pose pas entre le serveur X et les applications, mais que le serveur X est central et que le WM cause avec X tout comme le font les applications.
Le problème ne se pose donc pas. Et ça se confirme si on y regarde d'un peu plus près. Car XCB - tout comme la Xlib - cause directement avec le protocole X11, donc directement avec le serveur XFree86. Au final XCB et Xlib font la même chose, mais de façon différente. XCB semblant d'ailleurs avoir une bien meilleure architecture générale que la Xlib. Et ça ne s'arrête pas qu'au mode asynchrone. Allez donc voir la page XCB sur freedesktop.org
Résultat : il n'y a aucune raison pour qu'une applications utilisant la Xlib ait des problèmes à cause que le WM lui il utilise XCB. C'est là toute la base de la discussion sur la ML de e. Moi en tout cas ça m'a bien éclairé sur ce qu'est vraiment XCB. À noter que Rasterman est semble vraiment entousiasmé par cette nouvelle lib ^^
Vala. L'explication est suffisamment claire ?
Ha! Y'a aussi une ébauche de discussion sur l'intérêt réel de XCB, notamment mis en rapport avec Xorg (ou xouvert). Pas vraiment de réponse donné cependant. Mais à ce que j'ai cru comprendre XCB est bénéfique pour tout serveur X, car cette lib vient en remplacement ou se pose en concurrence de la Xlib. Je pense donc que XCB peut parfaitement être intégré à un autre serveur X. Surtout lorsque ceux-ci ont la même base : XFree86.
Au final je pense que XCB devrait être bénéfique aussi à Xorg et xouvert. Miam d'avance ^^
[^] # Re: C'est donc ça ?
Posté par Julien Portalier . En réponse à la dépêche XCB : bientôt la version 1. Évalué à 1.
Mias il est vrai qu'en 3D ça commence à se faire vraiment très très vieux... idem pour la qualité en 2D, ces cartes commencent à se faire vieilles. Mais après il est dur de trouver des équivalents en dualhead :(
# À quand les dictionnaires de langue ?
Posté par Julien Portalier . En réponse à la dépêche Encyclopédie Hachette Multimédia sous Linux. Évalué à 3.
Enfin, si les encyclopédies commencent à arriver pour notre manchot préféré et de façon intelligente (xul), on peut se dire que les dicos vont suivre la marche. J'aimerai bien voir rappliquer le robert & collins version 2 tomes en version numérique exploitable sous gnu/linux...
Nota: si quelqu'un a de très bon dicos d'anglais-français (et inversement) libres qu'il n'hésite pas à me le faire savoir ^^ Perso je n'ai pas trouvé grand chose. Mon dico le plus complet c'est un anglais-japonais... ce qui n'est guère des plus pratiques, vu que je baragouine à peine un peu de jpn ^^
[^] # Re: Quelques outils :
Posté par Julien Portalier . En réponse au journal un Access-like libre ?. Évalué à 3.
Sauf que ça marche pas. J'arrive bien à définir des accès à des BDD, mais mergeant ne me laisse pas les sélectionner lorsque je veux me connecter. La liste des BDD définies - reste désespéremment vide.
D'ailleurs pourquoi il ne va pas chercher les bases de données disponibles tout seul comme un grand comme le fait PHP My Admin ? Il suffirait de sélectionner un backend (XML, MySQL, etc.) ainsi qu'un login et hop : il nous donne la liste des BDD auxquelles on a accès et on peut s'y connecter.
C'est idiot de devoir définir les BDD disponibles...
Ou alors y'a un truc que j'ai pas compris et c'est franchement pas user-friendly (un comble pour une appli GNOME 2).
[^] # Re: Quelques outils :
Posté par Julien Portalier . En réponse au journal un Access-like libre ?. Évalué à 2.
[^] # Re: VNC ??
Posté par Julien Portalier . En réponse au journal Migration vers Linux dans mon entreprise : un frein majeur..... Évalué à 1.
Mais est-il vraiment nécessaire de devoir prendre le contrôle d'un PC à distance ? L'ouverture d'une session X distante permet largement d'installer des logiciels. Une simple connexion SSH devrait être largement suffisante d'ailleurs, sachant qu'il existe des logiciels permettant de contrôler simultanément plusieurs xterm en même temps. Ceci permet de mettre à jour tout un parc d'ordinateur d'une seule commande centrale, tout en voyant les résultats poste par poste.
Perso je ne vois pas le besoin nécessaire à devoir prendre le contrôle d'une session distante (à part installer un trou dans la sécurité des postes). Sauf si c'est pour pouvoir dépanner une session d'un utilisateur sans bouger ses fesses de son bureau ^^
# Euh...
Posté par Julien Portalier . En réponse au message Formulaire avec upload de fichiers. Évalué à 3.
Car dans ton exemple tu prends 'tmp_name' comme étant un répertoire dans le lequel tu vas trouver 'name', alors que 'tmp_name' est déjà le nom du fichier temporaire, avec tout son chemin. Et oui ç a un nom bizarre du style "/tmp/php??????".
Toi tu fais :
$img = ImageCreateFromJPEG( $_FILES['userfile']['tmp_name'].'/'.$_FILES['userfile']['name'] );
Et ça c'est faux.
[^] # Re: bof...
Posté par Julien Portalier . En réponse au journal DLFP carbure au régime totalitaire.. Évalué à 4.
Je suis tout à fait d'accord. C'est vrai que c'est amusant d'avoir un grade. Et encore plus lorsque les noms sont drôles ^^
Java a certes des qualités, mais putain qu'il est lent, en plus d'être propriétaire. Heuresement mono/.NET arrive pour nous sauver. J'espére que ce sera de base dans la Suse, seule distrib réellement pro (debian serait bien si elle était plus à jour, quand aux BSD, quand leur licence sera acceptable, on aura fait un grand pas en avant)...
Mouarf, concentré de trolls détecté. Bien vivaces en plus. Faire gaffe : reproduction en cours. D'ailleurs : ayant testé quelques applis Mono j'avoue être agréablement surpris : c'est loin d'être désagréable et lourd comme n'importe quelle application Java (mode graphique) sur un même système. J'aimerai bien voir une même application codée optimalement pour Java et pour Mono, histoire de voir la différence (réactivité, consommation cpu & mémoire, etc.)
# Magnatune.com
Posté par Julien Portalier . En réponse au journal La musique libre que vous aimez. Évalué à 2.
Perso j'écoute beaucoup (et je vais acheter d'ailleurs tellemnt c'est bon)
- Beth Quist
- Cargo Cult
- Very Large Array
- Solace
Voilà déjà de bons artistes. Mais je suis loin d'avoir écouté tous les artistes de magnatune (je me réfrène aussi, sinon ça va me coûter cher au final: ben ouais, la musique de qualité et qu'on est pas obligé de payer, ben tout de suite ça donne envie de donner un peu d'argent... surtout quand c'est pas à de méchants raquetteurs).
[^] # Re: rhythmbox
Posté par Julien Portalier . En réponse au sondage iTunes sous Linux ?. Évalué à 3.
Après si tu veux seulement une avancée de XMMS vers GTK+2 et quelques trucs : http://beepmp.sf.net/(...)
Mais personnelement je pense que l'idée de XMMS2 est bien intéressante. Avoir un démon qui s'occupe de tout ce qui est playlist/lecture, etc et qui le fait superbement bien. Et ensuite des frontends (qu'on peut quitter sans que ça coupe la musique, pratique pour libérer de la mémoire) en veux-tu en voilà qui font chacun exactement ce qu'on leur demande de faire (un truc à la rythmbox qui gère votre collection de MP3 ou un bête truc tout simple où qu'on glisse ses fichiers audio dessus).