Je suis assez d'accord pour dire que les attributs sont une aberration. Ils étaient logique en HTML : l'attribut représente la mise en forme, le reste est du texte.
Mais avec XML on a perdu cette sémantique, pire, avec XHTML, on met la forme dans un fichier séparé ...
Alors, non, je n'utiliserai pas les attributs quand j'en aurai le choix, mais mon problème est que je ne définierai pas tous les formats XML que je serai mené à utiliser ...
Le gros problème d'XML en ce moment, selon moi, c'est que beaucoup d'outils existent, mais que les gens ne les utilisent pas forcément (je radote avec les histoires de DTD et de schémas XML ;-) ). Ou alors ils utilisent XML parce que ça fait bien, mais sans réel besoin : j'ai envie de flinguer à peu près tous les programmeurs qui utilisent XML pour faire des fichiers de config, par exemple. Si dans certains cas ça peut parfaitement se justifier (par exemple un fichier de config Apache en XML, ça ne changerait pas tellement du fichier de config original), dans la plupart des cas, une bête association clef-valeur(s) (éventuellement séparées par des virgules) est largement suffisante.
Complètement d'accord avec toi ... cet effet de mode est pénible ...
Mais dans le cas de données très structurées, c'est la verbosité d'XML qui est pénible ... le format à base de parenthèses proposé au dessus m'aurait semblé bien plus malin. (je ne connais pas ou presque LISP, mais ça n'est qu'un format qui ressemble au LISP.
C'est un point de vue que tout le monde ne partage pas.
Peut être, mais dans l'industrie où les éditeurs répondent aux besoins des développeurs, on retrouve aujourd'hui la boucle foreach (ou similaire) en : C++ , Java, C#, Python, Ruby. Là encore t'as le droit de ne pas être d'accord, mais tu peux comprendre que dans la vraie vie c'est ce qui se passe.
Ta (vraie) vie à l'air d'effectivement se résumer à l'industrie.
Dans ce cas, tu as tout à fait raison de limiter ta vision des langages à java et c#, mais ne viens pas pourrir une news intéressante par tes troll et ton agressivité s'il te plaît.
Ce que je retiens de tes arguments, c'est 2 choses :
- si c'est différent de ce qui se fait actuellement, c'est mal (ça aide pas à évoluer, ça ...)
- si je tu tu sais pas ou si tu ne comprends pas, tu critiques (constructif ...)
Devant ton attitude, j'ai décidé de ne plus répondre à tes messages, comme pas mal d'autres ici. Tu es vraiment trop de mauvaise foi.
Ben l'à priori avec lequel je suis parti c'est : "tiens, un nouveau langage bien prétentieux". Ben oui il va "sans doute" remplacer le C c'est marqué. Donc je me dis qu'il doit être sacrément bien foutu et doit constitué un espèce de "state of art" de ce qui se fait en matière de langage, parcque pour déboulonner le C quand même...
Est-ce que ce n'est pas ce qu'annoncent tous les langages ? Le nouveau langage qui révolutionne tout et remplacera tout ce qui existe jusqu'à maintenant. Je ne pense pas que grand monde ici y croie vraiment, mais de là à descendre Lisaac comme tu le fais ...
- une grammaire simplissime, c'est paraît-il mieux pour les optimisations globales. Oui mais : au final c'est pas plus rapide que le C, donc première déception. Donc l'intérêt est pour moi limité.
Ce qu'il dit, c'est que du code Lissac écrit dans une optique de bonne architecture et donc assez facile à comprendre générera du code C optimisé mais imbitable. Je veux bien le croire. Si Lissac permet d'obtenir les mêmes performances que du C écrit dans une optique d'optimisation agressive mais en restant maintenable, ça n'est peut être pas une révolution, mais c'est déjà une bonne évolution non ?
- la possibilité de faire ses propres instructions d'itération & co : comme l'a dit quelqu'un ca ressemble beaucoup à de la masturbation intellectuelle qu'à autre chose. De ma petite expérience de programmation, c'est déjà assez affreux d'avoir à relire les macros C++ d'un collègue, alors si en plus je lui laisse la possibilité de fabriquer sa propre boucle for... Bref, pour moi ca n'a strictement aucun intérêt, c'est comme si le langage français avait 10 mot dans sa grammaire et qu'on avait tous nos dialectes bien à nous pour parler. Personne se comprend.
Et pourtant ... la bibliothèque standard C++ fournit différent mécanismes pour simplifier l'écriture de boucle dans l'en-tête <algorithms> (for_each & co). Encore une fois, ce n'est pas parce qu'une fonctionalité n'est pas dans le langage qu'elle n'est pas standard.
Je n'aime pas non plus cette philosophie (qu'on retrouve par exemple dans java) selon laquelle il faudrait prendre le développeur pour un dangereux terroriste et ne lui fournir la possibilité de ne faire que des choses sans danger. Parfois il est utile de faire ce qui ailleurs est une erreur de conception. Laissons la liberté au programmeur en précisant quand même les dangers de chaque construction.
- un truc magique et révolutionnaire breveté dans le compilateur. C'est gentil mais bon en attendant on est face à un compilateur qui demande des ressources de compilation exponentielles qui doive le rendre inutilisable dans le monde industriel, et qui pond du code pas plus rapide que du C.
Sur ce point là, je te rejoins complètement. Ca n'enlève pas les qualités intrinsèques du langage qui reste utile comme proof of concept et qui fournira peut être des outils utiles à d'autres langages plus pragmatiques. C'est un peu comme ça que fonctionne la recherche, ça ne me choque donc pas de la part d'un langage développé à l'INRIA.
- pour un langage qui veut remplacer le C, il est pas capable de présenter des APIs "àla C" réutilisables dans d'autres langages. En gros j'ai bien l'impression que si l'OS est en Lisaac, tout le reste doit l'être aussi. Bref aucune réflexion sur la transition et l'intégration avec l'existant.
Si le compilateur génère du C, je pense qu'il n'est certainement pas très compliqué d'ajouter la possibilité d'insérer des appels de fonction C qui ne doivent pas être traduits. On sort cependant là du cadre de la recherche et je pense que c'est en mûrissant que le langage sera agrémenté de ce genre de possibilités.
- pas de réflexion sur le versionning, la documentation du code ou encore la documentation sous forme de schéma : comment représente-on une modélisation visant ce langage ? UML est-il adapté ? Sinon y'a-t-il des outils ?
Tu cherches vraiment la petite bête. On te dis "un nouveau langage est créé avec une nouvelle manière de penser" tu réponds "est-ce qu'il est prêt pour la production ? est-ce que tous les outils qui vont autour sont disponibles ?"
Ce n'est pas Sun ou Microsoft qui proposent leur langage pas super innovant mais vachement bien supporté, c'est une équipe de recherche qui présente le résultat de ses travaux. Je pense que la plupart de tes problèmes avec le langage viennent de ce que tu attends autre chose que ce que fournit le langage.
Je vais essayer de ne pas tomber dans le troll, mais je crois que pour résumer ma pensée, je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
Je viens de relire toute la page et l'ensemble de tes commentaires. Je me demande ce que t'ont fait les développeurs de Lisaac pour que tu partes avec autant d'à prioris contre ce langage ... <humour>un concurent à c# ?</humour>
Je ne suis moi même pas convaincu qu'on ait là le langage qui remplacera le C.
Je dois avouer que j'aime quand même bien l'idée d'un langage minimaliste où tout est extensible.
Ton argument selon lequel, je cite
moins de constructions dans le langage ==> moins de contraintes de programmation ==> trop de liberté ==> trop de manière d'écrire le même code, difficulté de relecture par un autre programmeur, difficulés de maintenance, bugs potentiels.
me semble être lié à un raisonnement un peu rapide.
Ce n'est pas parce qu'une fonctionalité n'est pas inscrite dans la grammaire du langage qu'elle n'est pas standard. Il existe aussi la notion de bibliothèque standard.
Je ne suis pas suffisamment connaisseur du fonctionnement des compilateurs pour argumenter sur l'autre argument.
Par contre, si je comprend bien, ce compilateur analyse le code en entier avant de le compiler. J'imagine donc que le temps de compilation doit être relativement élevé. Surtout qu'il faut ensuite compiler le C généré ... Sur un gros projet, ça peut être très handicapant.
Le problème est que c'est une construction valide et parfois utile. Il est donc difficile de faire des tests automatisés pour vérifier qu'il n'y a pas confusion ...
Tu as raison de parler de sentiment de sécurité.
Tout d'abord, parce que c'est la raison qui fait que ces caméras sont là (si elles n'avaient aucune utilité, on ne payerai pas pour les installer)
Ensuite parce que de nombreuses études (et là, je ne pourrai pas citer mes sources, désolé) montrent que la vidéosurveillance ne diminue pas la délinquance. Elle contribue au mieux à la déplacer en participant ainsi à l'effet de ghettoisation.
Je penses que tu as aussi raison de penser que tu trouvera peu de soutient ici,dans la mesure où j'imagine que ceux qui choisissent le logiciel libre sont des gens qui aiment suffisement la liberté pour ne pas lui préférer un sentiment de sécurité.
Je trouve par contre ton dernier argument qui touche au sentimental assez bas. Il est facile d'avoir ce genre d'argument de n'importe quel côté :
"êtes vous heureux que la vie de vos enfants soit ainsi exposé en permanence aux yeux de ceux qui sont peut être des pédophiles ? Pensez aux parents de la petite Marion et ceux d'Estelle et de tant d'autres ?"
Je pertinentise quand même ton commentaire, parce que je pense que tu exprimes l'opinion majoritaire en Françe, mais qui aura du mal à se faire entendre ici.
Je pense que la loi ne rentrera pas dans les détails techniques de manière aussi pointue que tu le fait.
Ce que tu proposes ressemble cependant beaucoup au concept de "licence globale".
Cette fameuse "licence globale" acceptée en première lecture par les députés (mais elle ne passera pas hein !) fonctionne comme ça :
- ceux qui le désirent peuvent payer la licence globale
- ils ont alors accès légalement au contenu disponible sur internet (p2p, serveur centralisé comme tu le propose, etc ...)
- les autres continuent à fonctionner dans le système actuel
- les revenus de cette licence sont reversés aux auteurs
L'idée n'est pas mauvaise ... MAIS ceux qui font du lobbying à l'Assemblée ne sont pas les artistes, ce sont les majors.
Au Royaume Uni, un élu (à moins que ce ne soit un ministre, enfin, bref ...) poussait fortement en faveur d'une loi qu'on pourrait résumer comme ça : "Si vous recevez un fichier chiffré suspect (par exemple, si il fournit des informations liées au terrorisme), vous êtes tenus de livrer la clef permettant de le déchiffrer à la justice."
Un petit malin a sortit son PGP et a envoyé au monsieur un mail crypté dans lequel il expliquait dans le détail où et comment il allait bientôt commettre un attentat.
Il a ensuite diffusé l'information selon laquelle ce mail était suspect.
Le problème est que le destinataire était incapable de fournir la clef de déchiffrage, tout simplement parce qu'elle ne lui avait pas été transmise.
Je crois que ça avait fait pas mal de bruit à l'époque. Le texte n'est pas passé.
Alors, oui, l'idée est bonne. Même si ce genre d'action ne suffit pas à empêcher une loi de passer, ça peut faire une certaine impression sur l'opinion publique.
Reste à trouver un exemple aussi frappant. Il faut par contre bien étudier le texte et vérifier que l'exemple n'est pas juste à la limite du texte, sinon, on risque de passer pour des cons ...
[1] c'est une anecdote qui a quelques années et qui sort de ma mémoire, je l'ai donc certainement enjolivée un peu, mais le fond est vrai. Si quelqu'un d'autre en a le souvenir ...
Selon toi, parce qu'un célèbre inconnu (ze-dinosaur) a été du même avis que Linus Torvalds (Gnome limite trop les options accessibles) puis qu'il s'est rétracté parce que son problème particulier n'était qu'un bug, cela signifie que Linus Torvalds avait tord ?
Dans ce cas :
Je suis d'accord avec toi.
Je m'étais trompé.
Euh ... soit tu es bien mieux informé que moi, soit tu ne l'es pas du tout, soit tu es un trolleur invétéré ...
De toute façon il y aurra forcément du code en GPL v3...
C'est justement là qu'est le débat, et il semble pour l'instant que ce ne soit pas l'éventualité la plus probable.
Linus demande a tout le monde de passer en GPL v2 ou suivante (difficile a cause du nombre de contributeur et sans utiliser "qui ne dit mot consent")
Surtout qu'il dit justement sur la lkml que lui même ne le fera pas
Linus interdit le code GPL v3 only (autant se tirer une balle dans le pied)
Si tu le dis, c'est pourtant se qui se dessine.
Linus oblige la double license du nouveau code en GPL v3
Encore une fois, la dépèche fait justement suite aux propos de Linus Torvalds qui dit qu'il n'aime pas la GPLv3 pour Linux et qu'il ne l'adoptera donc pas ...
Enfin bon, dans tous les cas, a terme on passera en GPL v3...
Ce n'est pas l'avis de tout le monde, notamment de Linus Torvalds, un "contributeur important au noyau"
L'essentiel est que cette license oblige a effectivement a redistribuer les améliorations dans le code source et nous protège des perversions des véroux proprios dans le noyau (et les autres logiciels libres)...
Ta phrase et très obscure et sens la propagande à plein nez, mais je n'en comprend pas le sens.
Est-ce que ce n'est pas aussi ce que visait la GPLv2 ?
D'après Linus Torvalds, la GPLv3 amène des problèmes plus qu'elle n'en résout par rapport à la v2.
Quelles sont les raisons qui te font dire qu'il faudra de toute façon passer en v3 ?
Je crois que Linus Torvalds ne parle pas de clefs utilisées pour signer un logiciel, mais, au contraire, de clefs utilisées pour permettre de déchiffrer du contenu protégé par des DRM.
Il fait,à mon avis, bien soin de laisser ça flou pour laisser le troll prendre de l'ampleur, ce qui a deux effets :
- Ça sert de caisse de raisonance à son message
- Ça fait peur sur le contenu de la GPLv3
Je pense au contraire (comme Mat) que la GPLv2 n'est pas compatible avec la GPLv3.
Une bonne partie du code du noyau étant en "GPLv2 seulement", tu ne peux pas intégrer du code en "GPLv3 seulement" ni même en "GPLv3 ou supérieur".
Ce que tu peux par contre continuer à faire c'est d'intégrer du code en "GPLv2 ou supérieur" ou du code en "GPLv2 ou 3" voir du code en "GPLv2 ou ce que tu veux".
The only thing that the kernel requires is that since the majority of the
code is actually GPLv2-only, that in order for you to be able to link with
the code, your license has to be GPLv2-compatible.
A "GPLv3 _only_" license is not compatible with GPLv2, since v3 adds new
limitations to re-distribution. But what you can do is to dual-license the
code
Pour ceux qui ont peur des betes à poil, je préviens, je risque d'en réveiller une ici.
Pour commencer, je dois avouer que je suis tout à fait d'accord avec gnap gnap, c'est vraiment pas dans l'esprit du libre (tel que je le vois) de faire ce que fait Cannonical. "C'est pas du jeu" ;)
Sur la forme maintenant. Puisque c'est là que se situe le débat, je crois. Tel que je le comprend, rien ne permet de dire que ce logiciel n'est pas libre. C'est la meme astuce qu'utilise (c'est ici que je me souviens d'un troll déjà vu) Free.
Sur la FreeBox, j'ai cru comprendre que des logiciels libres modifiés sont utilisés, sans redistribuer les sources. Ces logiciels sont libres, on ne peut pas le nier (ils sont sous GPL, si je ne m'abuse ...). Il ne sont par contre pas distribués puisque la FreeBox appartient à Free, et, du coup, Free ne se sent pas obligé de redistribuer le code.
Je crains qu'on trouve de plus en plus d'exemples de ce type. Des entreprises qui profitent du libre sans complètement jouer le jeu ...
Tu me fais peur quand tu utilises ce genre d'argument.
Les logiciels libres sont bien là pour une question de liberté. Libre à chacun de l'utiliser à sa guise. Et si tu n'aime pas les pseudo longs, c'est ton droit. Personne ne t'oblige à posséder dans ta liste de contacts les personnes qui ont cette pratique.
Par contre, tu serais gentil de laisser ceux qui sont heureux d'avoir un pseudo long, qui sont heureux d'en changer régulièrement et qui sont heureux que leurs contacts fassent pareil tranquilles.
Cet argument que tu utilises n'a pas été utilisé que par des personnes respectables dans l'histoire, même très récente.
Tel que je le comprend ... mais je ne suis pas un expert non plus :
Tu n'es pas obligé d'inclure le source d'un morceau[1] de ton logiciel à condition que :
a) Ce morceau[1] soit relativement standard, c'est à dire distribué avec un morceau[2] (relativement) indispensable du système.
b) Ce morceau[1] de ton logiciel ne sert que si tu utilise le morceau[2] du système.
(les [1] et [2] ne renvoient pas à des notes de bas de page, mais tentent de désemberlificoter un minimum le texte en faisant la distinction entre les deux "morceaux")
Donc, amha, c'est par exemple pour permettre d'utiliser des morceaux de la bibliothèque standard de java dont on peut pas distribuer de sources.
Par contre, KDE, qui reposait entièrement sur Qt ne rentrerait pas dans le moule.
J'ai hésité avant de poster ce commentaire dans la mesure où ce genre d'explications faites par un néophyte font souvent plus de mal que de bien en lançant de pseudo rumeurs infondés. A prendre avec des pincettes, donc.
il est plus difficile pour le firmware qui tourne sur le chip intégré à la carte d'aller prendre le contrôle du noyau que pour le pilote qui est déjà exécuté sur le CPU en mode privilégié...
J'avais entendu parler d'ordinateurs portables auxquels on avait greffé une simple petite mémoire entre le clavier et le reste.
Dans ces conditions, meme avec le système logiciel le plus libre du monde, il est relativement simple pour le SAV de récupérer tes mots de passe et données sensibles.
Attention, une fois de plus, je ne fais pas l'apologie du propriétaire ("de toute façon, on peut récupérer mes mots de passe meme sous linux, autant repasser sous windows")
Je ne fais que dire : concentrons nous sur le plus urgent, les pilotes propriétaires qui reposent sur une ABI fixe. Le reste viendra après.
Un article était passé dans GNU Linux Magazine France à ce sujet.
Ce qu'il m'en reste est que Sun a posé trois conditions pour obtenir le droit de développer une machine virtuelle. Aucune n'interdit de faire une machine virtuelle libre.
C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué
En espérant ne pas avoir trop déformé le fameux article.
Ça lui ouvre nettement plus de possibilités pour planter le système ou contenir du code malicieux sans qu'on le sache...
J'ai du mal à comprendre qu'on puisse faire planter le système plus facilement avec du code qu'avec du matériel.
Une carte mal développée peut endommager ma carte mère, elle peut ne pas tout à fait effectuer ce que lui demande le système, elle peut corrompre la mémoire ...
Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.
Mais comprend qu'il y en a qui ont besoin d'un Linux fiable.
Là n'est pas le problème. Je reprend mon argument précédent. Si le logiciel est écrit avec les pieds, ton linux n'est pas fiable, mais si le matériel a une erreur de conception, ton serveur risque encore plus ...
Certes, l'une des raisons qui pousse pas mal de monde à refuser d'utiliser les pilotes propriétaires est leur réputation d'instabilité.
Je pense que c'est se tromper de bataille. Le vrai problème est de garder une alternative libre.
Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.
Alors peut etre que je me trompe mais la fameuse couche glue de nvidia dans le noyeau linux est opensource (forcément sinon ça peut pas marché avec tout les noyeau) mais pas du tout libre!
je pensais que cette couche avait été modifiée pour fonctionner avec les noyaux 2.6 par exemple quand ils n'étaient pas supportés par nvidia.
Je ne suis pas du tout sur de moi, passons sur ce "détail".
Ensuite le problème d'avoir une couche pas libre ou que ce soit c'est qu'on ne peut pas faire evoluer le système. exemple si on décide d'utiliser plutot directfb que x.org a partir de demain il faudras atendre que nvidia fasse des pilotes une nouvelle couche glue et tout.
Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.
En tout cas moi mon avis c'est de ne pas faire de concession, il faut rester libre meme si ça doit ralentir la propagation de linux. je prefaire que linux soit moins utilisé mais propre plutot que répandu mais tainted dans tous les sens. Ne passont pas du coté obscur pour plus de pouvoir.
Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.
Dans le cas de ce genre de pilotes (ceux où "c'est le driver qui en gere une tres grosse part [du boulot]") si la couche d'adaptation (glue) est bien faite, je suis près à faire des concessions dans mes revendications libristes.
Prenons le cas du driver nvidia. Essayons de ne plus penser en terme d'opposition matériel/logiciel. Il y a donc une couche supérieure, connectée au noyau, qui est libre et tout ce qui est plus bas niveau est propriétaire (logiciel et matériel). J'ai même cru comprendre que cette couche bas niveau était à peu près la même sous linux ou windows.
Il n'existe presque aucun matériel libre, et personne ne crie au scandale. En quoi cette couche de logiciel est-elle intrinsèquement différente ?
Ce que nous demandons, ce sont les spécifications du matériel. Et si c'est l'interface de cette couche logicielle qu'on nous fournit, comment doit on réagir ?
Le véritable problème réside dans le deuxième type de pilotes. Ceux qui sont distribués sous formes de binaires adaptés à une seule distribution. Ceux là devraient être évités à tout prix. Mais les utilisateurs de ces pilotes sont bien souvent des entreprises qui ont choisi linux uniquement par pragmatisme, pas du tout par amour du libre.
Les distributions pour lesquelles ces pilotes sont écris on en plus un avantage par rapport aux concurrents. Ça ne va pas les pousser à crier au scandale. Et même, ces distributions emploient bon nombre de développeurs noyau qui vont, eux aussi, avoir un jugement biaisé.
Tout ça ne fait pas de nvidia le bon samaritain du libre, mais sachons établir des priorités dans notre recherche de liberté.
Et demain, il faudra eteindre mon serveur pour protester contre la guerre en Irak, puis, après demain, parce qu'on a osé refuser l'entrée à Richard Stallman au Mac Donald's ...
Ce qui fait la beauté du libre, c'est aussi la liberté qu'il t'accorde.
Si tu veux te lancer dans ce genre d'action, c'est un beau geste. Si tu en inclus l'obligation dans la licence, le faire n'a plus aucune signification.
En plus, je passerai bien vite à un autre logiciel, à la license moins contraignante, et je pense que je ne serai pas le seul.
Et il semble même qu'avec un double clic sur l'image ouverte avec "ouvrir avec kuickshow" tu arrive sur la fameuse interface.
Ceci dit, vu le nombre de commentaire dans ce sens, il faudrait peut être que les super experts en "usabilité" tellement à la mode en ce moment se penchent sur le sujet.
Un grand bravo aussi. J'ai personellement tenté d'utiliser mediawiki récemment, mais j'ai abandonné quelques heures plus tard en ayant l'impression d'avoir sous les yeux un "moteur pour wikipedia" et pas un "moteur de wiki".
Vous m'avez prouvé que j'avais tord et qu'avec du travail, c'est un bel outil.
Une question me turlupine quand même (si, si ...)
Est-ce que vous ne perdez pas un peu l'avantage du wiki avec le système de modérateurs.
Une idée qui me semblait intéressante serait d'avoir une page de type wiki, non modérée, et régulièrement, le modérateur passerait faire un "freeze" pour générer la page à laquelle on accède par défaut. (1 page stable, et une page de développement ...)
Quelles sont les raisons qui vous ont poussé à ne pas faire ce choix ? Sont-elles d'ordre technique ou s'agit-il d'une volonté de votre part ?
[^] # Re: Est-ce que Lyx ne risque pas d'être un cul-de-sac?
Posté par Julien . En réponse à la dépêche LyX 1.4 est disponible. Évalué à 1.
Mais avec XML on a perdu cette sémantique, pire, avec XHTML, on met la forme dans un fichier séparé ...
Alors, non, je n'utiliserai pas les attributs quand j'en aurai le choix, mais mon problème est que je ne définierai pas tous les formats XML que je serai mené à utiliser ...
Complètement d'accord avec toi ... cet effet de mode est pénible ...
Mais dans le cas de données très structurées, c'est la verbosité d'XML qui est pénible ... le format à base de parenthèses proposé au dessus m'aurait semblé bien plus malin. (je ne connais pas ou presque LISP, mais ça n'est qu'un format qui ressemble au LISP.
[^] # Re: Euh ...
Posté par Julien . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 3.
Ta (vraie) vie à l'air d'effectivement se résumer à l'industrie.
Dans ce cas, tu as tout à fait raison de limiter ta vision des langages à java et c#, mais ne viens pas pourrir une news intéressante par tes troll et ton agressivité s'il te plaît.
Ce que je retiens de tes arguments, c'est 2 choses :
- si c'est différent de ce qui se fait actuellement, c'est mal (ça aide pas à évoluer, ça ...)
- si je tu tu sais pas ou si tu ne comprends pas, tu critiques (constructif ...)
Devant ton attitude, j'ai décidé de ne plus répondre à tes messages, comme pas mal d'autres ici. Tu es vraiment trop de mauvaise foi.
[^] # Re: Euh ...
Posté par Julien . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 5.
Est-ce que ce n'est pas ce qu'annoncent tous les langages ? Le nouveau langage qui révolutionne tout et remplacera tout ce qui existe jusqu'à maintenant. Je ne pense pas que grand monde ici y croie vraiment, mais de là à descendre Lisaac comme tu le fais ...
Ce qu'il dit, c'est que du code Lissac écrit dans une optique de bonne architecture et donc assez facile à comprendre générera du code C optimisé mais imbitable. Je veux bien le croire. Si Lissac permet d'obtenir les mêmes performances que du C écrit dans une optique d'optimisation agressive mais en restant maintenable, ça n'est peut être pas une révolution, mais c'est déjà une bonne évolution non ?
Et pourtant ... la bibliothèque standard C++ fournit différent mécanismes pour simplifier l'écriture de boucle dans l'en-tête <algorithms> (for_each & co). Encore une fois, ce n'est pas parce qu'une fonctionalité n'est pas dans le langage qu'elle n'est pas standard.
Je n'aime pas non plus cette philosophie (qu'on retrouve par exemple dans java) selon laquelle il faudrait prendre le développeur pour un dangereux terroriste et ne lui fournir la possibilité de ne faire que des choses sans danger. Parfois il est utile de faire ce qui ailleurs est une erreur de conception. Laissons la liberté au programmeur en précisant quand même les dangers de chaque construction.
Sur ce point là, je te rejoins complètement. Ca n'enlève pas les qualités intrinsèques du langage qui reste utile comme proof of concept et qui fournira peut être des outils utiles à d'autres langages plus pragmatiques. C'est un peu comme ça que fonctionne la recherche, ça ne me choque donc pas de la part d'un langage développé à l'INRIA.
Si le compilateur génère du C, je pense qu'il n'est certainement pas très compliqué d'ajouter la possibilité d'insérer des appels de fonction C qui ne doivent pas être traduits. On sort cependant là du cadre de la recherche et je pense que c'est en mûrissant que le langage sera agrémenté de ce genre de possibilités.
Tu cherches vraiment la petite bête. On te dis "un nouveau langage est créé avec une nouvelle manière de penser" tu réponds "est-ce qu'il est prêt pour la production ? est-ce que tous les outils qui vont autour sont disponibles ?"
Ce n'est pas Sun ou Microsoft qui proposent leur langage pas super innovant mais vachement bien supporté, c'est une équipe de recherche qui présente le résultat de ses travaux. Je pense que la plupart de tes problèmes avec le langage viennent de ce que tu attends autre chose que ce que fournit le langage.
Je vais essayer de ne pas tomber dans le troll, mais je crois que pour résumer ma pensée, je te trouve un peu dur avec un langage qui apporte des idées intéressantes si on ne le considère pas comme une fin en lui même.
[^] # Re: Euh ...
Posté par Julien . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 5.
Je ne suis moi même pas convaincu qu'on ait là le langage qui remplacera le C.
Je dois avouer que j'aime quand même bien l'idée d'un langage minimaliste où tout est extensible.
Ton argument selon lequel, je cite
me semble être lié à un raisonnement un peu rapide.
Ce n'est pas parce qu'une fonctionalité n'est pas inscrite dans la grammaire du langage qu'elle n'est pas standard. Il existe aussi la notion de bibliothèque standard.
Je ne suis pas suffisamment connaisseur du fonctionnement des compilateurs pour argumenter sur l'autre argument.
Par contre, si je comprend bien, ce compilateur analyse le code en entier avant de le compiler. J'imagine donc que le temps de compilation doit être relativement élevé. Surtout qu'il faut ensuite compiler le C généré ... Sur un gros projet, ça peut être très handicapant.
[^] # Re: Euh ...
Posté par Julien . En réponse à la dépêche 23 mars: Conférence au LORIA sur Lisaac, un nouveau langage. Évalué à 1.
if (b=true) /* ... */;
Le problème est que c'est une construction valide et parfois utile. Il est donc difficile de faire des tests automatisés pour vérifier qu'il n'y a pas confusion ...
[^] # Re: Liberté et liberté
Posté par Julien . En réponse à la dépêche Big Brother Awards 2005. Évalué à 8.
Tout d'abord, parce que c'est la raison qui fait que ces caméras sont là (si elles n'avaient aucune utilité, on ne payerai pas pour les installer)
Ensuite parce que de nombreuses études (et là, je ne pourrai pas citer mes sources, désolé) montrent que la vidéosurveillance ne diminue pas la délinquance. Elle contribue au mieux à la déplacer en participant ainsi à l'effet de ghettoisation.
Je penses que tu as aussi raison de penser que tu trouvera peu de soutient ici,dans la mesure où j'imagine que ceux qui choisissent le logiciel libre sont des gens qui aiment suffisement la liberté pour ne pas lui préférer un sentiment de sécurité.
Je trouve par contre ton dernier argument qui touche au sentimental assez bas. Il est facile d'avoir ce genre d'argument de n'importe quel côté :
"êtes vous heureux que la vie de vos enfants soit ainsi exposé en permanence aux yeux de ceux qui sont peut être des pédophiles ? Pensez aux parents de la petite Marion et ceux d'Estelle et de tant d'autres ?"
Je pertinentise quand même ton commentaire, parce que je pense que tu exprimes l'opinion majoritaire en Françe, mais qui aura du mal à se faire entendre ici.
[^] # Re: Et pratiquement...
Posté par Julien . En réponse à la dépêche DADVSI : c'est reparti. Évalué à 1.
Ce que tu proposes ressemble cependant beaucoup au concept de "licence globale".
Cette fameuse "licence globale" acceptée en première lecture par les députés (mais elle ne passera pas hein !) fonctionne comme ça :
- ceux qui le désirent peuvent payer la licence globale
- ils ont alors accès légalement au contenu disponible sur internet (p2p, serveur centralisé comme tu le propose, etc ...)
- les autres continuent à fonctionner dans le système actuel
- les revenus de cette licence sont reversés aux auteurs
L'idée n'est pas mauvaise ... MAIS ceux qui font du lobbying à l'Assemblée ne sont pas les artistes, ce sont les majors.
[^] # Re: Copier-Coller des 2 fichiers "doc"
Posté par Julien . En réponse à la dépêche DADVSI : c'est reparti. Évalué à 3.
Au Royaume Uni, un élu (à moins que ce ne soit un ministre, enfin, bref ...) poussait fortement en faveur d'une loi qu'on pourrait résumer comme ça : "Si vous recevez un fichier chiffré suspect (par exemple, si il fournit des informations liées au terrorisme), vous êtes tenus de livrer la clef permettant de le déchiffrer à la justice."
Un petit malin a sortit son PGP et a envoyé au monsieur un mail crypté dans lequel il expliquait dans le détail où et comment il allait bientôt commettre un attentat.
Il a ensuite diffusé l'information selon laquelle ce mail était suspect.
Le problème est que le destinataire était incapable de fournir la clef de déchiffrage, tout simplement parce qu'elle ne lui avait pas été transmise.
Je crois que ça avait fait pas mal de bruit à l'époque. Le texte n'est pas passé.
Alors, oui, l'idée est bonne. Même si ce genre d'action ne suffit pas à empêcher une loi de passer, ça peut faire une certaine impression sur l'opinion publique.
Reste à trouver un exemple aussi frappant. Il faut par contre bien étudier le texte et vérifier que l'exemple n'est pas juste à la limite du texte, sinon, on risque de passer pour des cons ...
[1] c'est une anecdote qui a quelques années et qui sort de ma mémoire, je l'ai donc certainement enjolivée un peu, mais le fond est vrai. Si quelqu'un d'autre en a le souvenir ...
[^] # Re: prévisualisation des images jointes ?
Posté par Julien . En réponse à la dépêche La version 2.0 de Sylpheed-Claws est sortie !. Évalué à -1.
[^] # Re: tropollesque
Posté par Julien . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 0.
Selon toi, parce qu'un célèbre inconnu (ze-dinosaur) a été du même avis que Linus Torvalds (Gnome limite trop les options accessibles) puis qu'il s'est rétracté parce que son problème particulier n'était qu'un bug, cela signifie que Linus Torvalds avait tord ?
Dans ce cas :
Je suis d'accord avec toi.
Je m'étais trompé.
Voilà, dorénavant, tu as tord ... CQFD
[^] # Re: Rien de surprenant
Posté par Julien . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 2.
C'est justement là qu'est le débat, et il semble pour l'instant que ce ne soit pas l'éventualité la plus probable.
Surtout qu'il dit justement sur la lkml que lui même ne le fera pas
Si tu le dis, c'est pourtant se qui se dessine.
Encore une fois, la dépèche fait justement suite aux propos de Linus Torvalds qui dit qu'il n'aime pas la GPLv3 pour Linux et qu'il ne l'adoptera donc pas ...
Ce n'est pas l'avis de tout le monde, notamment de Linus Torvalds, un "contributeur important au noyau"
Ta phrase et très obscure et sens la propagande à plein nez, mais je n'en comprend pas le sens.
Est-ce que ce n'est pas aussi ce que visait la GPLv2 ?
D'après Linus Torvalds, la GPLv3 amène des problèmes plus qu'elle n'en résout par rapport à la v2.
Quelles sont les raisons qui te font dire qu'il faudra de toute façon passer en v3 ?
[^] # Re: J'ai pas compris...
Posté par Julien . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 3.
Il fait,à mon avis, bien soin de laisser ça flou pour laisser le troll prendre de l'ampleur, ce qui a deux effets :
- Ça sert de caisse de raisonance à son message
- Ça fait peur sur le contenu de la GPLv3
[^] # Re: Rien de surprenant
Posté par Julien . En réponse à la dépêche Le noyau Linux ne se convertira pas à la GPLv3 !. Évalué à 6.
Une bonne partie du code du noyau étant en "GPLv2 seulement", tu ne peux pas intégrer du code en "GPLv3 seulement" ni même en "GPLv3 ou supérieur".
Ce que tu peux par contre continuer à faire c'est d'intégrer du code en "GPLv2 ou supérieur" ou du code en "GPLv2 ou 3" voir du code en "GPLv2 ou ce que tu veux".
C'est ce qu'il me semble en tout cas, et c'est aussi l'opinion de Linus Torvalds (Cf http://lkml.org/lkml/2006/1/27/339 )
[^] # Re: UbuntuMac
Posté par Julien . En réponse à la dépêche Nouveautés dans le monde Ubuntu. Évalué à 5.
Pour commencer, je dois avouer que je suis tout à fait d'accord avec gnap gnap, c'est vraiment pas dans l'esprit du libre (tel que je le vois) de faire ce que fait Cannonical. "C'est pas du jeu" ;)
Sur la forme maintenant. Puisque c'est là que se situe le débat, je crois. Tel que je le comprend, rien ne permet de dire que ce logiciel n'est pas libre. C'est la meme astuce qu'utilise (c'est ici que je me souviens d'un troll déjà vu) Free.
Sur la FreeBox, j'ai cru comprendre que des logiciels libres modifiés sont utilisés, sans redistribuer les sources. Ces logiciels sont libres, on ne peut pas le nier (ils sont sous GPL, si je ne m'abuse ...). Il ne sont par contre pas distribués puisque la FreeBox appartient à Free, et, du coup, Free ne se sent pas obligé de redistribuer le code.
Je crains qu'on trouve de plus en plus d'exemples de ce type. Des entreprises qui profitent du libre sans complètement jouer le jeu ...
[^] # Re: Evangéliser...
Posté par Julien . En réponse à la dépêche Jabber explose !. Évalué à 8.
Tu me fais peur quand tu utilises ce genre d'argument.
Les logiciels libres sont bien là pour une question de liberté. Libre à chacun de l'utiliser à sa guise. Et si tu n'aime pas les pseudo longs, c'est ton droit. Personne ne t'oblige à posséder dans ta liste de contacts les personnes qui ont cette pratique.
Par contre, tu serais gentil de laisser ceux qui sont heureux d'avoir un pseudo long, qui sont heureux d'en changer régulièrement et qui sont heureux que leurs contacts fassent pareil tranquilles.
Cet argument que tu utilises n'a pas été utilisé que par des personnes respectables dans l'histoire, même très récente.
[^] # Re: une explication.. ?
Posté par Julien . En réponse à la dépêche Première ébauche de la GPLv3. Évalué à 6.
Tu n'es pas obligé d'inclure le source d'un morceau[1] de ton logiciel à condition que :
a) Ce morceau[1] soit relativement standard, c'est à dire distribué avec un morceau[2] (relativement) indispensable du système.
b) Ce morceau[1] de ton logiciel ne sert que si tu utilise le morceau[2] du système.
(les [1] et [2] ne renvoient pas à des notes de bas de page, mais tentent de désemberlificoter un minimum le texte en faisant la distinction entre les deux "morceaux")
Donc, amha, c'est par exemple pour permettre d'utiliser des morceaux de la bibliothèque standard de java dont on peut pas distribuer de sources.
Par contre, KDE, qui reposait entièrement sur Qt ne rentrerait pas dans le moule.
J'ai hésité avant de poster ce commentaire dans la mesure où ce genre d'explications faites par un néophyte font souvent plus de mal que de bien en lançant de pseudo rumeurs infondés. A prendre avec des pincettes, donc.
[^] # Re: Le risque n'est pas le même
Posté par Julien . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à -1.
J'avais entendu parler d'ordinateurs portables auxquels on avait greffé une simple petite mémoire entre le clavier et le reste.
Dans ces conditions, meme avec le système logiciel le plus libre du monde, il est relativement simple pour le SAV de récupérer tes mots de passe et données sensibles.
Attention, une fois de plus, je ne fais pas l'apologie du propriétaire ("de toute façon, on peut récupérer mes mots de passe meme sous linux, autant repasser sous windows")
Je ne fais que dire : concentrons nous sur le plus urgent, les pilotes propriétaires qui reposent sur une ABI fixe. Le reste viendra après.
[^] # Re: Question de "newbe"
Posté par Julien . En réponse à la dépêche SUN libère ses processeurs SPARC. Évalué à 6.
Ce qu'il m'en reste est que Sun a posé trois conditions pour obtenir le droit de développer une machine virtuelle. Aucune n'interdit de faire une machine virtuelle libre.
C'est par contre quasiment impossible. En effet, une de ces conditions interdit de fournir une machine virtuelle qui n'est pas 100% compatible aux normes de SUN. Il faut donc finir le produit avant de le distribuer, ce qui est très compliqué
En espérant ne pas avoir trop déformé le fameux article.
[^] # Re: Le risque n'est pas le même
Posté par Julien . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 0.
J'ai du mal à comprendre qu'on puisse faire planter le système plus facilement avec du code qu'avec du matériel.
Une carte mal développée peut endommager ma carte mère, elle peut ne pas tout à fait effectuer ce que lui demande le système, elle peut corrompre la mémoire ...
Je pense par contre que le code est souvent écris plus "à la vas vite" et c'est certainement la raison qui fait qu'on a plus confiance en le matériel.
Là n'est pas le problème. Je reprend mon argument précédent. Si le logiciel est écrit avec les pieds, ton linux n'est pas fiable, mais si le matériel a une erreur de conception, ton serveur risque encore plus ...
Certes, l'une des raisons qui pousse pas mal de monde à refuser d'utiliser les pilotes propriétaires est leur réputation d'instabilité.
Je pense que c'est se tromper de bataille. Le vrai problème est de garder une alternative libre.
Si la fiabilité est la préoccupation numéro un, il existe des unices propriétaires qui font très bien leur travail.
[^] # Re: C'est parti ..
Posté par Julien . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à -1.
je pensais que cette couche avait été modifiée pour fonctionner avec les noyaux 2.6 par exemple quand ils n'étaient pas supportés par nvidia.
Je ne suis pas du tout sur de moi, passons sur ce "détail".
Biens sur, mais continuons dans mon analogie en considérant cette surcouche logicielle comme une extension du matériel. Si j'achète un modem, je ne peux pas l'utiliser comme répondeur téléphonique. Je me limite par rapport à un winmodem, mais personne ne vient se plaindre, au contraire. On se simplifie la vie avec des primitives plus haut niveau, mais on diminue les possibilités, c'est certain.
Quelles belles paroles, je pense qu'à peu près tout le monde ici est d'accord avec toi.
Cependant, quand il s'agit de mettre ces paroles en application, les choses se corsent.
Il existe des systèmes qui ont toujours été plus rigoureux sur l'application du libre que linux. Je pense notament à GNU. Es-tu pour autant un utilisateur du Hurd ?
Meme parmis les distributions linux, certaines sont plus rigoureuses, par exemple debian, mais celle-ci perd des utilisateurs au profit d'autres, telle qu'ubuntu.
Quel est le problème ? Tout simplement, plus de rigueur signifie moins de performances, moins de performances, moins d'utilisateurs, moins d'utilisateurs, moins de contributeurs, moins de contributeurs, moins de performances ... C'est un cercle vicieux.
[^] # Re: C'est parti ..
Posté par Julien . En réponse à la dépêche Pilotes binaires dans Linux: quel est le problème ?. Évalué à 5.
Prenons le cas du driver nvidia. Essayons de ne plus penser en terme d'opposition matériel/logiciel. Il y a donc une couche supérieure, connectée au noyau, qui est libre et tout ce qui est plus bas niveau est propriétaire (logiciel et matériel). J'ai même cru comprendre que cette couche bas niveau était à peu près la même sous linux ou windows.
Il n'existe presque aucun matériel libre, et personne ne crie au scandale. En quoi cette couche de logiciel est-elle intrinsèquement différente ?
Ce que nous demandons, ce sont les spécifications du matériel. Et si c'est l'interface de cette couche logicielle qu'on nous fournit, comment doit on réagir ?
Le véritable problème réside dans le deuxième type de pilotes. Ceux qui sont distribués sous formes de binaires adaptés à une seule distribution. Ceux là devraient être évités à tout prix. Mais les utilisateurs de ces pilotes sont bien souvent des entreprises qui ont choisi linux uniquement par pragmatisme, pas du tout par amour du libre.
Les distributions pour lesquelles ces pilotes sont écris on en plus un avantage par rapport aux concurrents. Ça ne va pas les pousser à crier au scandale. Et même, ces distributions emploient bon nombre de développeurs noyau qui vont, eux aussi, avoir un jugement biaisé.
Tout ça ne fait pas de nvidia le bon samaritain du libre, mais sachons établir des priorités dans notre recherche de liberté.
[^] # Re: Et pourquoi pas une riposte pour montrer les effets ?
Posté par Julien . En réponse à la dépêche À l'approche de l'examen du projet de loi relatif au DADVSI, les webradios se mobilisent. Évalué à 2.
Ce qui fait la beauté du libre, c'est aussi la liberté qu'il t'accorde.
Si tu veux te lancer dans ce genre d'action, c'est un beau geste. Si tu en inclus l'obligation dans la licence, le faire n'a plus aucune signification.
En plus, je passerai bien vite à un autre logiciel, à la license moins contraignante, et je pense que je ne serai pas le seul.
[^] # Re: Bof bof
Posté par Julien . En réponse à la dépêche Ksquirrel : nouvelle visionneuse pour KDE. Évalué à 3.
Ceci dit, vu le nombre de commentaire dans ce sens, il faudrait peut être que les super experts en "usabilité" tellement à la mode en ce moment se penchent sur le sujet.
[^] # Re: Bravo Léa !
Posté par Julien . En réponse à la dépêche Léa en wiki. Évalué à 1.
[^] # Re: Bravo Léa !
Posté par Julien . En réponse à la dépêche Léa en wiki. Évalué à 4.
Vous m'avez prouvé que j'avais tord et qu'avec du travail, c'est un bel outil.
Une question me turlupine quand même (si, si ...)
Est-ce que vous ne perdez pas un peu l'avantage du wiki avec le système de modérateurs.
Une idée qui me semblait intéressante serait d'avoir une page de type wiki, non modérée, et régulièrement, le modérateur passerait faire un "freeze" pour générer la page à laquelle on accède par défaut. (1 page stable, et une page de développement ...)
Quelles sont les raisons qui vous ont poussé à ne pas faire ce choix ? Sont-elles d'ordre technique ou s'agit-il d'une volonté de votre part ?