Raphael Junqueira a écrit 337 commentaires

  • [^] # Re: bibliothéque partgée

    Posté par  . En réponse au journal Le protocole MSN et ses supports libres. Évalué à 2.

    Pour la webcam, ils travaillaient dessus comme le tableau partage

    pour le partage de dossiers, il faudrait que la personne qui en ait l utilite le fasse ;p
  • [^] # Re: bibliothéque partgée

    Posté par  . En réponse au journal Le protocole MSN et ses supports libres. Évalué à 5.

    elle existe déjà :
    http://tiagosh.wordpress.com/category/libmsn/

    est maintenue et supporte (ou pas loin de supporter) toutes les dernières "évolutions" du protocole

    Je pense que pymsn y gagnerai a travailler avec les devs de libmsn
    (tant qu'ils sont motivés)
  • [^] # Re: May the 64bits be with you !

    Posté par  . En réponse au journal Les enfants, un grand moment de l'Histoire se prépare.... Évalué à 3.

    Non justement le long sous unix correspond a la longeur d'un mot machine (donc en 64bits, 64bits) par contre le long long reste sur bien des plateformes 64bits. Et seul le int reste en 32bits.

    Par contre sous windows (histoire d'emmerder le monde) le long reste 32bits (il faut alors utiliser le tres portable __int64)
  • [^] # Re: Gnome, toujours trois trains de retard

    Posté par  . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.

    > Ce que tu sembles oublier c'est que le langage C avait été choisi
    > parcque justement il était facile à "binder". . KDE n'a pas
    > forcement la primeur en la manière.

    Cela existe en effet depuis des annees. Mais si tu lit bien le commentaire auquel tu repons il ne parle que de "la primeur de KDE" par rapport a gnome. De plus l'interet du binding KDE est la facon dont tout est automatise et genere de telle maniere a que ce soit le plus integre dans la philosophie du langage cible (et c'est le meme script te genere le binding pour tous les langages)

    > De plus créer un binding sur KDE est très (trop) limité : D'où le
    > choix pour Gnome de C qui a l'avantage d'être un dénominateur
    > commun à tous les langages : ils sont tous capables d'utiliser le C (ou
    > presque). Je parle même pas d'un hybride C++ qui nécessite un
    > précompilo si tu vois ce que je veux dire.

    Je ne voit pas comment tu peux dire ca. Tu devrais jeter un oeil au bindings KDE avant de parler. Mis a part le binding c (ex: qtc) qui est un peu horrible a regarder (car tu dois comme gnome faire de l'object sans object) les autres sont complets.
    Le langage C++ au lieu de poser des problemes, comme tu pense le penser, permet (par son defaut d'etre assez verbeux au niveau des headers) de belles choses.

    > En C++, en parsant le .h, tu as 99% de l'info dont tu as besoin.
    > Ben en C aussi dis donc.

    tres belle demonstration, tu as deja vu des headers C++ de KDE ? :)

    > Même si j'ai encore des doutes sur l'intérêt, le mécanisme mis en place
    > dans les libs compatible "Gnome" (à la glib quoi) permettent
    > l'introspection, ce que ne permettent absoluement pas les libs KDE.

    Mais bien sur. Et la marmotte ...
  • [^] # Re: Gnome, toujours trois trains de retard

    Posté par  . En réponse à la dépêche Toutes les API GNOME dans tous les langages et pour bientôt ?. Évalué à 3.

    > visiblement les "bindeurs" KDE n'en ont pas eu besoin pour faire de la
    > génération automatique, les .h leurs suffisent.

    Ca n'est pas totalement vrai.
    Cela est vrai pour les bindings des langages "statiques" (ex: C) par contre pour les langages "dynamiques" (du genre python, ruby, etc...) le binding exploite a fond les capacites de moc

    > Je vois pas pourquoi il ne serait pas de même pour Gnome et ses .h.

    Il est plus facile de partir de bcp d'informations (ie. typage assew fort dans les headers c++) et de "degrader" que le contraire (probleme du fameux "void*" du c)
  • [^] # Re: Sérieusement...

    Posté par  . En réponse à la dépêche Des petits jeux pour les fêtes. Évalué à 2.

    Il est certain que l'on peut difficilement comparer es jeux "libres" aux jeux commerciaux dont bon nombre ont actuellement un budget au dela du demi-million d'euros (dont une faible partie servira a financer le developpement)


    Je me dis aussi qu'il est plus facile de trouver des personnes connaissant moyennement DirectX dans son ensemble (cad. 3d+son+réseau+entrées/sorties) que d'autres pouvant mettre en ½uvre le même "spectre" de fonctionnalités avec des équivalents libres.
    No troll intended, c'est juste une opinion. Suis-je à côté de la plaque ?


    Je ne pense pas que cela soit plus facile :)
    Car generalement les "developpeurs de jeux "utilisent des moteurs (3D, sonore, physique, reseau) qu'ils ne font que modifier (apres s'etre acquitte de lourdes licences) et integrer ensemble (quand l'integration n'est deja pas faite). En fait peut de jeux exploitent pleinement DirectX, generalement a part Direct3D et DSound le reste est rarement utilise (globalement on pourrait faire la meme chose avec OpenGL et n'importe quel moteur sonore sous linux).
    L'epoque heroique ou chacun allait de son moteur 3D, sonore, ... n'est malheureusement plus et le niveau des devs a faible chute

    Par contre si jamais on en trouvait suffisement on peut parfaitement utiliser DirectX sous linux via wine/winelib :)

    FeniX
  • [^] # Re: Sortie d'aMSN 0.90

    Posté par  . En réponse à la dépêche Sortie d'aMSN 0.90. Évalué à 1.

    Kopete fait meme bcp mieux pcque il gere aussi les transfert de smileys customises (ie emoticons).
    En clair si un utilisateur d'un client "officiel" msn ayant customise des smileys (mapping cle/icone) en utilise, le destinataire devrait les affiches (les icones) commes elle ont ete voulues par l'envoyeur (et non pas le texte correspondant). Tout ca passe par un pseudo-protocole p2p que peut de clients msn supportent (a part kopete qui semble marche et kmess qui essaye j'en connait pas d'autres).
    Aussi le nouveau protocole de transfert de fichiers (a partir de msn8, que personne ne supporte reelement ce qui est tres chiant pour recevoir des fichiers) utilise aussi ce protocole p2p.
  • # Re: Nouveau vol de code source: C officiel, MS confirme :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 2.

    http://www.eweek.com/article2/0,4149,1526591,00.asp(...)

    Enfin, MS vient enfin a l'Open Source, et plus rapidement qu'on le pensait :p
    Qui c'est qui s'ouvre un CVS ?

    PBPG, tu pourrais completer car le code il est pas complet ? :)
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 0.

    lol
    j'aurais du aller me coucher plus tot :)
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 3.


    Si je savais qui a crée MyDoom ou qui a (peut être) volé le code je le denonce, j'empoche la recompense et je paye ca caution huhu :)


    C'est risquer dernierement aux US d'aller en prison pour des "raisons d'etat" (et oui ce virus a pas mal foutu la merde et pas mal impacter les interet des US).
    Il risquerait de passer pas mal de temps en prison avant d'avoir un procet.

    Ben ouais ce serais qd meme grace a lui que je serais devenu riche :))

    T'inquiete MS s'occuperait de toi avant :)

    PS.1: s/APPEL/APPELLE/
    PS.2: je presume qu'en ecrivant ce message en anglais et sur slashdot tu aurait surement plus de chance de succes
  • [^] # Re: Nouveau vol de code source :(

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 2.

    vi mais solaris et HPUX fournissent de base un make standard (non-gnu)
    donc ils n'avait pas de raison d'utiliser gnumake (enfin si pour apple, shut)
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 2.

    (Je me reply a moi meme)

    - record de primes sur sa tete

    Enfin si le code a vraiment ete vole, j'imagine meme pas la somme de la prime. Vu que deja celle pour un malheureux virus frole le delire ...
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 1.

    Pas a jour ta version, tu oublie que tout logiciel de SUN subit aussi des envoutements voudous de notre "systeme bien aime" :)
  • [^] # Re: Nouveau vol de code source :(

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 3.

    Bien sûr, mais là il y a un beau mélange de trucs connus, moins connus, à moitié en chantier, de sous-projets avec noms de codes rigolos, etc. C'est difficile d'imiter parfaitement un truc aussi imparfait (enfin bref, je me comprends).

    C sur, mais y a des geeks fous sur cette planete pret a tous pour leur moment de gloire :)

    Le code source de Windows est par ailleurs à la disposition de nombreuses personnes, y compris en dehors de Microsoft (grands comptes, universités, Chine et autres). Quand on y pense, c'est même surprenant qu'il n'y ait pas eu de fuite plus tôt.

    Oui, mais ayant vu un NDA qui protege ces versions je peut t'assurer que ca te passe vite l'envie de tenter quoi que se soit qui pourrait pas plaire a MS apres avoir signer (surtout qu'a coup sur il ont poses des watermark dans le code)

    Quoique je me rapelle d'une pseudo-fuite pendant l'été 2001, où un contractant Microsoft avait laissé en lecture un FTP qui contenait les sources de Windows XP (encore en développement à l'époque).

    Vi, la fuite que personne n'a jamais rien vu, un peu a la MS qui se plaignait il y a peu d'un DDOS de masse sur leur serveur :)
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 5.

    Je pense plutot que c'est un employe de microsoft qui a voulut entrer doublement dans le livre des records:
    - record de trolls sur slasdot en une journee
    - record de primes sur sa tete

    Enjoy :p
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 2.

    De toute facon les differences majeures entre Windows XP et 2K se sont les libraires de "haut niveau" (UI, etc...) plus que le kernel (une legere evolution de celui ci)
    Par contre si qqu'un pouvait faire leaker le code de user32 et autres dlls de l'UI ca peut m'interresser
  • [^] # Re: Nouveau vol de code source :(

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 5.

    La liste des fichiers semble complète et légitime
    Ca ca veut rien dire, rien n'aurait empecher un malade d'avoir passer qques semaines de sa vie pour la faire

    C'est quoi ces 185 gnumakefile qui trainent ?
    Ben tu veut qu'ils utilisent quoi a la place ?
    Le truc de VS qui est inutilisable des que le systeme de build deviant un peu tordy ?



    C'est quoi ces fichiers (awk.exe, chmod.exe, grep.exe...) dans win2k/private/inet/mshtml/build/scripts/tools/x86
    et win2k/private/inet/mshtml/build/scripts/tools/alpha ?


    Tu n'a jamais installer les "Unix Services" ?
    De plus si je me rappelle bien le dev de NT avait debutte sur des stations Unix (l'epoque de OS/2) donc cela est fort logique (ils auraient put au moins essayer perl au lieu de reste a awk qd meme)
  • [^] # Re: Nouveau vol de code source :)

    Posté par  . En réponse au journal Nouveau vol de code source :). Évalué à 0.

    Chez Microsoft ils connaissent les journaux ? :)
  • [^] # Re: Mandows 1.4

    Posté par  . En réponse à la dépêche Mandows 1.4. Évalué à 2.

    S'il fallait designer des equivalents entre les deux environnements de bureau, je parlerais de gedit/kate et de abiword/kwrite.

    ???
    tu est sur de savoir de quoi tu parle:
    Les programmes equivalent sont
    - notepad likes: kwrite / gedit
    - ultraedit likes: kate / pas d'equivalent (a la rigeur, et de loin anjuta)
    - traitement de textes: kword/ abiword
  • [^] # Re: Mandows 1.4

    Posté par  . En réponse à la dépêche Mandows 1.4. Évalué à 1.

    Oui, bon, que ce soit les libs ou les applis qui lancent le serveur ca change pas grand chose.

    Pour moi si, je prefere que mon desktop mette un peu plus de temps a demarrer mais qu'apres mes applis se lancent "rapidement" que de scotcher a chaque lancement d'applis "majeures"

    Evolution c'est pas un bon exemple, c'est lourd.

    Arf, ben si Evolution n'est pas un bon exemple je ne sait pas qu'est ce un bon exemple.
    Desole si moi j'ai le besoin d'un client mail integre avec un carnet d'adrresse, mes taches, mon palm, ...
    La j'utilise la suite kdepim mais j'utilisait evolution avant car ca correspondait a mes besoins (alors que balsa, mozilla et autres pas du tout)

    Mais lance fluxbox, puis compare le lancement de kedit et celui de gedit.

    Bon g installer gedit, juste pour te faire plaisir.
    Ca commence mal avec les 1.5Mo que prend le package.
    La je le lance en meme temps que kwrite sans environnement kde (le vrai equivalent a gedit sous kde) avec "gedit & kwrite" et ohh surprise quasi-exactement le meme temps de lancement (gedit prend une microseconde plus vite a se lancer) :)
    Le pire c que kwrite ne fait que 120Ko en lui meme (le reste ce sont les kdelibs de kde) et que fonctionnellement il fait plus de trucs (pas au niveau de kate mais des choses appreciables pour un notepad like)
  • [^] # Re: Mandows 1.4

    Posté par  . En réponse à la dépêche Mandows 1.4. Évalué à 6.

    Non, car en plus les applis KDE lancent tout un tas de serveurs. Fais le test, tu verras.

    Ce ne sont pas les applis kde, mais le coeur de kde (kdelibs) qui lance ces serveurs
    (principalement dcopserver, knotify, ksmserver et artsd). A la difference de gnome ou se sont les applis qui chargent leurs propres serveurs (essaye de lancer un evolution sous kde et tu verras qu'ils le meme probleme de kde mais du cote applis)

    Raphael
  • # Sauver Kopete :)

    Posté par  . En réponse au journal MSN et webcam. Évalué à 1.

    Ben justement je cherchait la meme chose (aussi pour la meme raison)
    Et en plongant dans le code du chtit kopete on peut voir que c prevu (y a un bo plugins netmeeting et qques bribes de codes dans le protocole msn) mais debranche au niveau du code.
    J'ai essaye d'activer le code mais ca fait pas grand chose, si qqu'un pouvait se devouer pour faire marcher tout ca, on sera deja deux de combles (au passage si vous pouviez regarder le transfert de fichiers msn...)

    Merci
  • [^] # Re: Anjuta 1.2

    Posté par  . En réponse à la dépêche Anjuta 1.2. Évalué à 1.

    En gros Kdevelop fait-il aussi bien le c/c++ que eclipse fait le java ?

    Pour du c++, il le fait tres bien mais il a moins aussi moins a gerer du fait que le langage de base ne possede pas autant de "fonctionnalites"

    Et Kdevelop fait-il mieux le java qu'eclipse ne fait le c/c++ ?

    Clairement, meme si au niveau de l'integration des beans et autres joyeusetes avancee de Java il est encore balbutiant (en gros il fait du java comme du c++: debuggeur, editeur, completion, gestion de classes, UML via umbrello mais rien de plus)
  • [^] # Re: Anjuta 1.2

    Posté par  . En réponse à la dépêche Anjuta 1.2. Évalué à 3.

    Un peu lent mais pas mal :)
    Il manque pas grand chose et ca me remplacerait bien ultra-edit sous windows
    allons voir dedans le bebe :)
  • [^] # Re: Anjuta 1.2

    Posté par  . En réponse à la dépêche Anjuta 1.2. Évalué à 2.

    kdevelop3 fait le python aussi.
    Regarde par la pour l'etat du support (qui ne cherche a s'ameliorer, il me semblait que qqu'un bossait sur le support deboggeur):
    http://developer.kde.org/documentation/library/cvs-api/kdevelop/htm(...)