lasher a écrit 2730 commentaires

  • [^] # Re: Moi qui croyait...

    Posté par  . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 1.

    La GPL et sa nature récursive (virale ?), ne permet pas de refermer l'accès au code et permet au logiciel d'avoir une descendance.

    Tu déformes un peu tes propos précédents je trouve : la GPL permet tout, y compris de rendre du code propriétaire (et donc d'obtenir une "feuille" dans l'arbre des développements) ; la GPL impose qu'on continue de développer l'arbre. C'est "tout".

    On peut comparer la licence BSD à la production des mulets, forts comme des chevaux et intelligents comme les ânes, mais stériles.

    Ben non, on ne peut pas. OpenBSD est un fork de NetBSD, mais est libre. DragonFlyBSD est un fork de FreeBSD 4.X, mais est libre. OpenSSH a pour base de départ la dernière version libre de SSH.

    La GPL ne fait pas confiance aux gens pour "coller" à l'esprit du libre toute leur vie, du coup elle leur impose. La licence BSD permet aux gens de faire comme ils l'entendent. A eux de prendre leurs responsabilités. Comme je le disais dans un message plus bas, la licence BSD fait qu'on considère comme la moindre des politesses de rendre un peu à la communauté qui a donné beaucoup. Maintenant, lorsqu'on te fait un cadeau, rien ne t'oblige à dire merci si tu n'en as pas envie, mais c'est pas poli.

    Dire que la licence BSD est stérile est un travestissement de la réalité. Elle permet juste aux égoïstes de l'être toujours, tout comme elle n'empêche pas les gens de contribuer au développement du logiciel considéré. Il y a sans doute beaucoup de gens qui font du proprio à partir de LL sous licence BSD (je ne parle même pas de ceux qui repompent des LL GPL honteusement), mais ils respectent les règles du jeu, et comme il n'est pas dans leur intérêt de trop trop aller vite dans leurs dévs (puisque s'ils rendent le logiciel "parfait", qui voudrait de la version suivante ?), ils risquent d'aller moins vite que le logiciel libre qu'ils ont repompé. Evidemment, ça suppose que ledit logiciel ait le soutien suffisant pour continuer à exister.
  • [^] # [HS]Vive les armes à feu ?!

    Posté par  . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 3.

    On voit ensuite je crois le résultat ici (documentaire que je recommande vivement):
    http://www.bowlingforcolumbine.com(...)


    Sauf que dans ce documentaire, M. Moore montre bien qu'au Canada, ils ont autant d'armes à feu qu'aux US, et qu'il y a clairement moins de meurtres.
  • [^] # Re: GPL-like vs BSD-like

    Posté par  . En réponse à la dépêche ESR : «Nous n'avons plus besoin de la GPL.». Évalué à 6.

    Globalement je suis d'accord avec ton analyse, mais il y a une chose que je trouve fausse :

    Un système de code GPL va donc avoir tendance à grossir et évoluer de manière naturelle alors que les systèmes de type BSD et propriétaire vont nécessiter un mécanisme actif permettant de garantir un flux entrant d'information (et ceci explique a priori le succès des licences GPL) [...] les systèmes BSD ne peuvent exister de manière stable et efficace face au propriétaire.


    Ce serait vite oublier la licence qui anime quelques très gros projets libres. Je pense notamment à X / Xorg, à Bind, Perl, Apache, etc. (bon certes, mis à part Xorg, dans les exemples précédents, il s'agit surtout d'outils pour les professionnels ou les amateurs éclairés).

    Ah oui, j'oubliais OpenSSH ! Bref, je trouve qu'on oublie bien vite que les gros projets libres, s'ils sont souvent sous GPL, sont aussi souvent sous une licence "BSDisante"...

    Lorsqu'on fait du logiciel libre sous licence BSD, on fait le pari que, si jamais le logiciel plaît, et qu'une boite veut le reprendre, celle-ci aura fort à faire pour rester à jour contre toute une communauté de développeurs motivés. Alors oui, la GPL force de facto les utilisateurs-programmeurs à rendre ce qu'ils ont emprunté. Les BSDistes préfèrent dire que c'est plus poli de faire ainsi, mais que chacun fait comme il veut. Et honnêtement, je ne vois pas comment un standard (au hasard, la pile TCP/IP) pourrait se répandre facilement si en intégrant le code dudit standard on doive changer la licence pour tout un projet (d'aucuns argueront que la LGPL est faite pour ça, mais la licence BSD est qd même préférée dans la majorité des cas)
  • [^] # Re: Nanard

    Posté par  . En réponse au journal Je suis honnête, je télécharge légalement. Évalué à 2.

    Et pour en revenir au P2P, télécharger des artistes peu connu ou peu vendu ou peu distribué, c'est aussi les priver du fruit de leur travail,

    C'est marrant, à un concert des Fatals Picards, un pote qui voulait acheter leur CD n'a pas pu : tous les disques étaient partis. Réponse d'Ivan (le chanteur) : "boah, t'as qu'à le télécharger sur le net".

    Ils sont pas cons les FP (et je dis pas seulement ça parce qu'ils paient des coups :) ) : ils savent très bien qu'ils gagnent beaucoup en laissant des morceaux sur le net, parce que ça ramène des gens à leurs concerts, que ça fait vendre des t-shirts, des CD, etc.
  • # Oooops

    Posté par  . En réponse à la dépêche Journée de découverte du Logiciel Libre à l'Université de Technologie de Compiègne. Évalué à 2.

    J'ai oublié de préciser que c'était très bientôt, le 26 (jeudi quoi ;-) ) !

    Venez nombreux !
  • [^] # Re: s/authentification/authentication/g

    Posté par  . En réponse à la dépêche Faille de sécurité dans les protocoles IPSec. Évalué à 6.

    Euh, le moinssage je m'en fous, mais vous savez que j'ai raison hein ? En Anglais, "Authentification" n'existe pas. Alors quand je vois un sigle mal retranscrit, désolé de vouloir rectifier...
  • # s/authentification/authentication/g

    Posté par  . En réponse à la dépêche Faille de sécurité dans les protocoles IPSec. Évalué à 4.

    tout est dans le titre :)
  • [^] # Re: Ditto

    Posté par  . En réponse au journal Globalement décevant. Évalué à 2.

    Euh, tu sais que c'était de la radio d'être un livre, hein ? tu le sais, ça ? :-)
  • [^] # Re: Plan 9 c'est l'avenir

    Posté par  . En réponse au journal Unix, que sont devenus tes concepts ?. Évalué à 0.

    Si l'affirmation n'était pas vraie, et bien on ne ferait rien de plus de nos ordinateurs qu'il y a 10 ans ! Or, aujourd'hui, on rippe des DVD, on grave des CD/DVD, on fait du montage vidéo, on lit du DivX, etc., tout ça en écoutant de la musique et en surfant sur internet, et en plus, pour un prix incroyablement plus bas qu'il y a 10 ans.

    L'affirmation n'est pas totalement fausse. Beaucoup de programmes sont écrits en VB/Delphi/etc. Une certaine quantité en Java, et bien sûr il y a C et C++, Perl, Python, Ruby, et les autres.

    Pour ne prendre que le cas de Java (mais c'est globalement vrai pour tous les langages), il existe beaucoup de programmeurs qui utilisent les mauvaises structures de données aux mauvais endroits. Ce qui implique que de la mémoire est franchement gâchée (non pas parce que lesdites structures sont mal codées, mais surtout mal employées). Cela fait dire à certains que Java est lent, ce qui est faux depuis un moment maintenant. Idem pour les langages de script.

    Je pense qu'il faut parler d'optimisation en faisant surtout un parallèle avec "bonne conception". Une bonne conception utilise les bonnes structures.

    Pour illustrer : si je me souviens bien, il y avait de gros soucis de perfs avec la VM dans Linux 2.4 (swap continu quasiment dès le départ dans certaines configurations du système). Le fait de changer le modèle pour la VM a résolu en grande partie le problème.

    Il est évident qu'il faut d'abord que "ça marche" et qu'ensuite seulement il est temps d'optimiser.

    Et sinon :


    ordinateur PC 486 SX 25 doté de 4 Mo de mémoire, avec une carte graphique 256 couleurs, un disque dur 120 Mo, un lecteur disquette 3"1/2 1,44 Mo, et sans écran (ni lecteur CD, ni carte son évidemment) pour la modique somme de 140.000 francs hors taxes, soit 166.040 francs TTC


    Ca me paraît vraiment énorme comme prix. A l'époque (à peu près au même moment), mes parents avaient acheté un 386 DX 33 avec 4Mo de RAM, 1Mo de vidéo, 120 Mo de HDD, un écran 14" qui montait jusqu'en 800*600 (1024*768 entrelacé). Le tout pour 14000F TTC.
  • [^] # Re: absence de recul

    Posté par  . En réponse au journal 100 minutes pour convaincre : le carnage !. Évalué à 0.

    Juste pour info, le sophisme à la base, c'est purement l'art de convaincre, ni plus ni moins. Un bon sophiste était censé pour voir parler de tout et convaincre son auditoire un jour que la pluie était ce qui pouvait arriver de mieux à la république, et le lendemain que le soleil et la sécheresse, c'était ça, le progrès.
  • [^] # Re: Sacré langage!

    Posté par  . En réponse à la dépêche Journées Perl 2005. Évalué à 0.

    Oui. Et dans ce cas tu ne prendras pas un langage interprêté, parce qu'à ma connaissance aucun n'est capable de ce genre de perfs. Donc ton argument n'a absolument aucune valeur.

    En apparté, pour ce qui est de la rapidité d'exécution/de la performance d'un code, je te renvoie à Abrash (Black book of programming, dispo gratuitement sur le net), au tout premier chapitre. En résumé : il démontre qu'à moins de maîtriser parfaitement l'assembleur (et donc la machine sur laquelle on programme, quelque part), la différence de performance entre un code écrit en c et d'un autre en ASM est négligeable. Et il écrivait ça il y a plus de 10 ans (à une époque où l'optimisation des compilateurs n'était pas ce qu'elle est maintenant), à l'époque des 486...
  • [^] # Re: Sacré langage!

    Posté par  . En réponse à la dépêche Journées Perl 2005. Évalué à 0.

      Il faudrait que tu précises alors. Parce que du Web dynamique en Perl, j'en ai fait, et ça se passe plutôt très bien.
      Au pire (et pour répondre à un message plus bas) il existe l'équivalent de php avec perl (avec les mêmes inconvénients aussi).
      L'overhead de Perl lorsqu'il est utilisé pour faire du cgi est extrêmement réduit dans le cas d'Apache, et ce grâce à mod_perl.
      Pour ceux qui parleraient (encore) de l'illisibilité de Perl vis à vis des autres langages, je ne vois pas trop quel est le problème.
      PHP est un langage qui peut lui aussi être très crade (car le code est embarqué au milieu du code HTML... Alors oui, on peut toujours faire des include, tout ça... Mais c'est quand même pas génial, ça force quand même à insérer du "<?php $maVar ?>" de temps à autres ...
      ... De même que le C ou le C++, pour ne prendre que ces langages comme exemple. Franchement, entre
    #include <stdio.h>
    #include <stdlib.h>
    #include <errno.h>
    
    int main(void) {
        FILE *f = NULL;
        char buffer[81];
        
        f = fopen("fichier.txt","r");
        while (fread(buffer, sizeof(buffer), f) != NULL) 
            printf("%s\n", buffer);
        if (ferror(f))
        {
            perror("fread");
            exit(errno);
        }
        if (fclose(f) != 0)
        {
            perror("fclose");
            exit(errno);
        }
        return EXIT_SUCCESS;
    }
    
    et
    #!/usr/bin/perl
    
    use strict;
    use warnings;
    
    open(FICHIER, "<fichier.txt") || die "Erreur à l'ouverture du fichier";
    print while(<FICHIER>); # erreurs détectées automatiquement
    close(FICHIER) || die "Erreur à la fermeture du fichier";
    
      Je me demande vraiment quel est le langage le plus illisible (et pourtant tous les deux peuvent être considérés comme lisibles je pense, sur un exemple aussi simple).
      Tout ça pour revenir à la même rengaine : c'est la conception qui compte plus que tout ...
      En Perl, c'est plus ou moins pareil, mais à l'envers : il faut insérer du code HTML dans du code Perl - et là on est heureux d'avoir des emprunts au shell du type :
    print << EOHtml
    <code HTML .../>
    EOHtml
    
      En Java, il y a Struts ou JSF (qui ont le bon goût de masquer le code Java en utilisant des balises - JSTL + Struts tags par exemple - ce qui permet de ne plus avoir de code Java dans 99% des cas à l'intérieur du JSP), voire d'utiliser XML+XSLT pour le rendu...
      ... Mais mon petit doigt me dit qu'il existe des choses équivalentes en Perl :-)
  • [^] # Re: Sacré langage!

    Posté par  . En réponse à la dépêche Journées Perl 2005. Évalué à 1.

    Par contre je ne suis pas sur que Perl soit aussi facile a gerer dans des contextes exigeant en terme de rapidite d'execution que le C justement ?


    J'avais fait une appli en Perl qui devait parser des mails, générer un fichier XML décrivant ces mails, contacter une base MySQL, utiliser Image Magick pour déterminer les dimensions d'une image .... Bref, faire des trucs assez complexes. Avec une contrainte : mon appli plus les traitements des autres applis (programmées en Perl elles aussi) ne devait pas dépasser 8 secondes de délai entre réception du mail et émission du SMS de confirmation...

    Mon petit parser de mail effectuait son boulot en moins de 0.5 seconde. Les autres applis en Perl faisaient à peu près pareil (avec en plus de l'analyse XML, des écritures dans la base, etc). Bref, Perl est rapide.

    En C, ça aurait sans doute pris moins de temps à l'exécution. Maintenant, les quelques millièmes de secondes gagnés par le programme en C sont négligeables devant les quelques semaines de dév gagnées grâce à Perl.
  • [^] # Re: Le Net rendu à son concept

    Posté par  . En réponse à la dépêche Vers un accès libre aux résultats de la recherche…. Évalué à 0.

    Salut

    Je ne suis pas certain que tu aies raison. Lorsque le Monde proposait de consulter ses archives en ligne, ses rédacteurs ont gueulé en disant (avec raison) qu'ils n'avaient été payés que pour une seule publication de l'article.

    En quoi ce cas-ci est-il différent ?
  • [^] # Re: roh

    Posté par  . En réponse au journal Enfin, je peux le dire: je recrute !!!. Évalué à 1.

    Par exemple pour jayacard, si tu n'as eu aucun contributeur, ça veut dire que personne ne s'y est interessé. Donc pas non plus un concurrent, donc.
    Si le projet avait été close source, ça n'aurait donc rien changé.


    C'est un raccourci un peu facile. Lorsque ton produit concerne la sécurité, et un support de sécu comme les cartes à puce, le côté "y'a pas beaucoup de monde" ne veut pas dire que le peu de monde qui s'intéresse à ce genre de solutions ne sera pas intéressé par tes idées.

    Et de même que des applications libres peuvent répliquer le fonctionnement d'un logiciel proprio en changeant l'algo qui parvient au même résultat, qu'est-ce qui empêche une société de repomper un logiciel libre (en ayant un avantage : le source est à disposition), et de modifier les parties de code qui vont bien ? Ils y auront gagné beaucoup de temps en dév qd même.

    Pire : une boite peu scrupuleuse pourrait très bien reprendre le code, le mettre en closed source, et comme il s'agit de cartes à puces, il serait difficile de prouver que le code est bien issu du libre.

    Dans le cas "générique", tu as peut-être raison : un produit "ultra-spécialisé", qui n'intéresse que peu de boites pourrait peut-être marcher dans le monde du libre. Mais là il s'agit d'un produit axé sécurité. C'est plus le même genre de produit selon moi.
  • [^] # Re: naturellement...

    Posté par  . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 1.

    Le cas ne s'est jamais posé dans mon entourage, j'en sais donc rien. Par contre, les cas où l'on fait une prise de sang à la demande des autorités c'est quand même pas fréquent...

    Donc tu crois vraiment que le cannabis ne jouera pas ? :-)

    Et je n'ai pas jugé comme bonne ou mauvaise la prise de cannabis, chacun fait comme il veut, et surtout chacun assume :-)
  • [^] # Re: naturellement...

    Posté par  . En réponse à la dépêche Déclarations de Microsoft à propos de l'interopérabilité, et réactions. Évalué à 0.

    Si la possession est illégale, la consommation aussi, non ? :)
    Et sinon, oui, consommer du cannabis c'est illégal. A ton avis, pourquoi on demandait la dépénalisation y'a pas si longtemps ?
  • [^] # Re: escalade dans la répression jusqu'aux échanges privés entre amis ?

    Posté par  . En réponse à la dépêche Appel du Nouvel Observateur contre la répression du peer-to-peer. Évalué à 1.

    Le simple fait que ce genre de knacky géant existe démontre ce que je dis ;-)

    En fait, le donut/knacky ne pourrait exister dans un régime totalitaire, qui estime que l'art a une fonction : celle de louer le régime.

    De plus, oui ça ouvre l'esprit : ce n'est pas parce que quelqu'un fait une oeuvre farfelue que ça ne peut pas t'interpeler :-)
  • [^] # Re: escalade dans la répression jusqu'aux échanges privés entre amis ?

    Posté par  . En réponse à la dépêche Appel du Nouvel Observateur contre la répression du peer-to-peer. Évalué à 1.

    Ce que j'appelle "l'art formatté" n'a d'art que le nom. Il y a évidemment une base artistique au départ (le peintre qui est engagé par le régime sait a priori peindre), mais il n'a pas réellement de liberté quant aux idées qu'il peut faire transparaître.

    Donc oui, tout artiste qui est libre de faire son oeuvre (même lorsqu'il s'agit d'une commande - on peut très bien demander un thème, sans forcer un artiste à représenter exactement le petit père des peuples en zoom 100:1 ...) peut inclure une part d'originalité.

    En ce qui concerne Céline, les pamphlets anti-sémites qu'il a écrits ne sont pas disponibles à la vente, il y a bien une raison ... [1]


    A vrai dire, je trouve ton argumentaire assez contradictoire
    J'estime qu'il ne suffit pas de savoir bien dessiner pour être un artiste, de même que ce n'est pas parce que j'ai une expression, une grammaire et une orthographe correctes que je suis un écrivain.

    Cela dit, c'est vrai que j'ai un peu embrouillé mon raisonnement dans mon précédent post.

    [1] Et la raison, c'est que ses descendants refusent qu'ils soient publiés, même à titre historique -- grand-papa était un grand artiste, pas ce sale raciste que certains jaloux prétendent qu'il était !
  • [^] # Re: escalade dans la répression jusqu'aux échanges privés entre amis ?

    Posté par  . En réponse à la dépêche Appel du Nouvel Observateur contre la répression du peer-to-peer. Évalué à 1.

    Tous les artistes ne mettent pas une dimension politique dans leur oeuvre

    Non, mais absolument toutes [1] les oeuvres d'artistes montrent qu'il existe une autre voie, une façon de penser différente.

    Avoir un art "formatté" permet d'asseoir sa mainmise sur un peuple.

    [1] oui, toutes, car toute oeuvre admise comme originale - c'est-à-dire pas un plagiat - est concernée
  • [^] # Re: Droit de réponse

    Posté par  . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 3.

    D'habitude c'est le contraire : on écrit "the answer to life, the universe, and everything" et google répond 42 (si si, essayez :-) )
  • [^] # [HS] UNIX et la qualité logicielle

    Posté par  . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.

    Juste une remarque un peu hors sujet :

    Actuellement (et depuis longtemps) et terme de fiabilité/qualité il n'y a que Unix qui arrive au niveau de Linux (et vice versa)

    Je te conseille de chercher sur le net le "UNIX Haters Guide" :
    http://www.simson.net/ref/ugh.pdf(...)

    Il a été écrit par un ingé de chez MS (bon à la limite, tu pourrais dire que quelque part c'est pas très surprenant), mais aussi par l'un des co-auteurs de "UNIX & Internet Security" (d'ailleurs dans ce dernier bouquin, il y est dit que les logiciels proprio sont beaucoup plus enclins aux bugs en ce qui concerne UNIX que leur équivalent libre - c'était en 96, vu que j'ai la 2è édition seulement :-) ).

    De plus il y a une "anti-préface" de D. Ritchie, qui vaut le détour ;-)

    Je trouve que ce bouquin est intéressant à lire (ne serait-ce qu'en diagonale) pour comprendre les limitations d'UNIX à l'époque... Le "longtemps" que tu donnes n'est donc pas si vrai que ça (le UHG date de 94)
  • [^] # Re: Droit de réponse

    Posté par  . En réponse à la dépêche Démarche qualité et Logiciel Libre. Évalué à 1.

    et pourquoi pas le développement Web ?

    Parce que si on le prend comme ça, cite-moi 10 projets issus PHP qui ne concernent pas les livres d'or, de webmail, de forums ... :-)

    En ce moment Java brille beaucoup par sa capacité à faire tourner des applis métier (web ou pas, on s'en fiche), donc du coup tu as Struts, Ant, Junit, Tomcat, JBoss, etc. qui sortent du lot. Mais on pourrait aussi parler de Eclipse, de NetBeans, de Jext, etc...
  • [^] # Re: escalade dans la répression jusqu'aux échanges privés entre amis ?

    Posté par  . En réponse à la dépêche Appel du Nouvel Observateur contre la répression du peer-to-peer. Évalué à 3.

    Ca ne sert ni a manger, ni a se loger, ni a se défendre d'une oppression...

    Tu as raison, c'est pour ça que les pays totalitaires choisissent leurs artistes et ce qu'ils ont droit de créer comme oeuvre. L'art n'est pas subversif, n'ouvre pas l'esprit, et ne permet pas de s'apercevoir des problèmes liés à notre société, pas du tout ...
  • [^] # Re: escalade dans la répression jusqu'aux échanges privés entre amis ?

    Posté par  . En réponse à la dépêche Appel du Nouvel Observateur contre la répression du peer-to-peer. Évalué à 1.

    A titre de comparaison: frauder dans les transports en commun expose la personne à une amende en plus du le prix du billet. On se retrouve pourtant dans le même cas que pour le logiciel: pas de perte mais un manque à gagner pour la société.

    Si, il y a des pertes : tu uses des sièges, tu salis des couloirs, etc.
    Tu coûtes à l'organisme de transports en commun. C'est sûr, c'est pas énorme. Mais quand tu te retrouves avec 1000 personnes faisant comme toi *tous les jours* ... (qui a dit "loi morale" ? :-)

    disclaimer : le "tu" est générique, bien sûr.