> C'est pas parcque t'utilises une couche de crypto qui utilise une technique d'encodage standardisé que ca devient une solution miracle : faut que le client dbus sache le consommer.
Comment fait HTTP, selon toi ? C'est écrit en dur dans la RFC 2616 ?
Ce que je voulais dire par "SSH" c'est pas "on fait un hack quick & dirty" mais "on peut faire sans complexifier la spec"
> Moi je prends un framework quelconque, style Java ou .NET, non y'a rien pour consommer un service DBus de base, et pourtant ces framework en implémente des standards
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
> C'est pas REST mais c'est non plus très loin.
Mais c'est qu'il récidive, le bougre :)
SOAP se traine vaguement au dessus d'un protocole de type REST comme un boulet au pied pour des raisons pratiques (HTTP, ça passe partout). La comparaison s'arrête là. SOAP, c'est du RPC, l'opposé de REST (dans les longs trolls du moins :p)
> Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;)
De la différence entre le fond et la forme...
> Ca c'est les types de base, mais si on veut représenter par exemple
> une date
timestamp ? RFC 822 ?
Encore une fois, tu crois qu'ils font comment, pour HTTP ? Ils définissent un type date, ou ils disent simplement "une date sera formatée comme défini dans la RFC xxx ou yyy, au choix. Toute autre date est indéfinie"
> Un type énuméré ?
Tu parles des "enum" du C ? un entier suffit largement...
> Une url ?
Comme tout le monde, par une chaine de caractères ?
> Y'a quoi pour spécifier de nouvaux formats ?
> Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
> Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
C'est si difficile que ça de se mettre d'accord entre devs ? (dans la doc technique, à tout hasard)
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par: les 397 moyens de passer par HTTP GET, HTTP POST, HTTP PUT, HTTP DELETE, FTP, SMTP, IPoT, l'authentification, la cryptholographie, la numérologie, la redundanc-scalability, 965 définitions de type (URL, Date, Path, Port, Range, Domain, User, Password, Service, ServiceInfo, ServiceInfoServer, ServiceInfoServerInfo, Toto, Tata, Tutu, Titi, Rominet) juste pour ça ?
> faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Non. Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
> Et là encore une fois, c'est toi qui a décidé de StartTransact et EndTransact : quand tout le monde aura comme toi réinventer la roue pour mettrte en oeuvre des opération atomiques à partir de plusieurs échanges de messages, certains vont se dire "et si on standardisait ca ?"
On peut le standardiser de la même manière que l'introspection...
Et l'implémenter de la même manière...
> c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
Non, c'est lié à la surcomplexification.
XML-RPC, du temps ou je l'ai vu, avait une spec de deux pages. Il ne nécessitait aucun outillage étrange de génération d'interfaces qui lui même génère des source qui génèrent..., et était entièrement implémentable en moins d'une journée avec l'aide d'une bonne lib XML
Dis moi, la spec de SOAP: combien de pages ? Pourrais tu t'en sortir sans la grosse artillerie d'IDEs, d'aides au dévellopement, d'aide aux outils de dev, d'aide aux outils d'aides aux outils de dev... ? Combien de temps pour implémenter complètement les specs (même de manière quick & dirty) ? Pour quel apport, finalement, par rapport à XML-RPC ?
Pour finir, même si tu as des outils qui te cachent la saleté sous le tapis, qu'est-ce que tu fais quand ils te lachent ? Si tu veux les débugger ?
Le but, c'est de pisser du code sans vraiment comprendre ce qui se passe en interne ou de faire quelque chose de relativement sûr qui ne donne pas de surprises ?
Si demain, ton application se met à merder après recompilation alors que tu n'as modifié que les commentaires, tu accuses qui ? Ton code ? Ou une des 360000 lignes autogénérées ? Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
Ce n'est pas parce que ça "parait" simple que "c'est" simple. Cacher la complexité derrière du code auto généré, c'est un peu comme la politique de l'autruche, ça ne résoud pas les vrais problèmes.
C'est de ce juste milieu que je parlais. Effectivement, c'est plus contre SOAP que contre WCF, je te l'accorde ;)
> SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message.
Non. SOAP permet de faire
- du passage de messages
- de définition de messages
- de validation de messages
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Avec chacun de ces points tellement complexe qu'il meriterait une spec à lui seul.
Faire une seule chose, c'est faire une seule chose simple, sinon c'est qu'on pouvait décomposer la chose en sous problèmes indépendants. C'est visiblement le cas de SOAP (pas de WCF, je te l'accorde, mais cf une citation précédente: "piling complexity...")
> C'est d'ailleur sans doute la première raison pour laquelle DBus n'utilise pas XML dans des messages textes par exemples : ils auraient pu s'appuyer sur l'existant mais pour des questions de perfs inter-process, rien ne vaut protocole optimisé pour les besoins que l'ont tente d'adresser.
Tu es de ceux qui pensent que HTTP devrait être réécrit en XML ?
Faut pas déconner, XML n'est pas LA solution universelle. Même s'il est adapté dans la très grande majorité des cas, la non utilisation de XML n'est pas forcément un pis-aller. SMTP, HTTP & co se basent sur l'existant: l'ASCII. C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ? Pour avoir le plaisir de dire "yeah, moi je suis xml-compliant" ?
Ce que j'ai comparé: l'API dbus/python et WFC. Pas dbus et WFC. Parce que comme tu le dis si bien, les deux n'ont rien à voir: WFC n'est rien d'autre qu'une API.
Et j'ai dit que l'API de dbus/python était aussi souple et plus simple, donc plus "sexy" à mon gout (et j'ai admis que ça WFC pouvait aussi être vu comme sexy par ceux qui n'ont connu que SOAP et les DCOM/CORBA).
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). J'aimerais seulement réagir sur quelque points, je ne peux pas te maisser dire de telles choses sur DBus...
> - comment je gère le cryptage de mes services de manière standards ?
tunneling SSH ?
> Je dois me coltiner un format qui n'a rien de standard ?
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
Et pour WCF, seule l'API est peut être standard, j'en sais rien. Mais tu peux implémenter un protocole non standard au dessus de ça, donc bon...
> Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Rassure moi, tu t'es mal exprimé, hein ?
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
> Les web-services répondent à une problématique bien précise : l'inter-opérabilité
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
> DBus c'est de l'événementiel ultra-simple.
DBus n'est pas uniquement événementiel. Il peut être utilisé comme ça (cf HAL), mais ce n'est pas obligatoire (ce que KDE va en faire, en gros)
> Simple parcque tout jeune.
Non. DBus n'est déjà plus tout jeune. Il est simple parce qu'il est VOULU simple. Unix. KISS. Tout ce que les programmeurs Java/C# ont oubliés depuis longtemps, quoi (troll inside, don't feed the troll :p)
> Demain ils vont vouloir exposer des services à travers internet
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
> toute les couches d'abstraction qui vont bien
Trop d'abstraction tue la simplicité, l'efficacité et au final même la souplesse fini pa en pâtir. À faire trop d'abstractions, on en finit par oublier les problèmes réels.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
> ils vont vouloir ajouter de l'introspection
Ça existe déjà. De manière SIMPLE et efficace
> ils vont chercher à standardiser la façon d'échanger certains types de données
cf remarques précédentes. Encore une fois, tu as l'air de penser que les problèmes complexes nécessitent des solutions complexes. C'est complètement faux. Dans la plupart des cas, simplicité implique souplesse, et la souplesse permet de régler simplement des problèmes complexes.
Actuellement, tout peut être représenté avec DBus (il y a les nombres (de différents types)), les chaines de caractères, les tableaux, les structures et les tableaux associatifs. Qu'est ce qui ne peut pas être construit à partir de ça ?
> les normes de cryptage
SSH. Pourquoi réinventer la roue, crévindiou ?
> d'authentification
Tu n'as visiblement pas compris quels étaient les buts de DBus
L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
> de transaction
Je vois pas ce que tu veux dire là dedans... Dans le même sens que les transactions des BDD ? Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
> DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
C'est LE point central.
Toute l'histoire des web services, ça a été "on met tout dans le protocole afin de simplifier la vie au programmeur". Au final, ça a donné les monstres de complexité que l'on connait.
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN. Si ensuite, on voit qu'il y a des besoins communs à tous les utilisateurs, alors on fait une bibliothèque partagée "dbus-utils" qui s'en occupe. C'est par exemple le cas de l'introspection. Les specs du protocole n'en parlent même pas. À la place, tu as des fonctions pour l'introspection dans les libs et un document séparé disant que "l'introspection se fait par l'intermédiaire de org.freedesktop.DBus.Introspectable.Introspect dont voici les paramètres et ce que ça doit donner en sortie". De la même manière, les propriétés sont gérées par une interface org.freedesktop.DBus.Properties. Que tu ne trouveras jamais dans les specs
du protocole, parce que son boulot, c'est JUSTE du RPC.
C'est ça la souplesse et la modularité. C'est autre chose que les montagnes d'abstractions qu'on voit dans le monde Java/.NET
> Ouah c'est une feature sexy
Mais tout dépend du référentiel :) (et c'est pour ça qu'on est pas d'accord, AMHA)
Comparé à ce que j'ai ouïe dire des SOAP, CORBA, DCOM & co, effectivement, c'est beaucoup plus simple et quelqu'un qui ne connaitrait que ça pourrait sincèrement dire "c'est vraiment sympa et sexy"
Mais comparé au couple dbus/python (ou dbus/quoi que ce soit d'autre, ne soyons pas sectaires), ça n'apporte rien de concrètement intéressant, surtout pour la complexité apportée (je le répète, relativement à dbus). Et je ne trouve pas ça sexy.
Je veux pas faire ma mauvaise langue, mais ça me fait fortement penser au système de GNOME qu'ils sont tout doucement en train d'abandonner au profit de quelque chose de plus simple comme dbus...
Ce qui me dérange, c'est qu'on commence à faire une énorme couche d'abstraction bien lourde juste pour le plaisir, sans qu'il y ait de réel besoin pour ça
Alors qu'une couche mince et simple aurait fait l'affaire
C'est à dire l'opposé complet des conseils de bonne programmation unix
Mais c'est dans la continuité des .NET, C#, Java & co après tout :)
Il répond très simplement: comparé à dbus, c'est pas beaucoup plus souple (oui, théoriquement, tu es indépendant du protocole. Mais en python aussi avec dbus, puisque c'est exactement la même chose: on fait tout avec des décorateurs et on ne définit qu'une api, pas un protocole !) et BEAUCOUP plus compliqué (avec dbus, c'est JUSTE des décorateurs. Pas de fichier de configuration, pas de fichier source autogénéré, pas de fichier interface autogénéré, rien. Juste quelques décorateurs).
Après, faut voir avec quoi tu compares. Si tu compares avec les anciennes technologies proprios de ce type, je n'en sais rien, je connais pas. Si tu compares à DBUS, ça n'apporte vraiment rien.
> Ce n'est pas l'OS qui va dicter si l'utilisateur TOTO de ton appli web a le droit d'accéder au formulaire administratif.
Effectivement, parce que le formulaire administratif n'est pas une ressource que l'OS gère
Mais moi, je répondais à:
>> accède à des fichiers auxquel je ne souhaite pas l'autoriser ou qui seraient sensibles.
Et les fichiers, c'est une ressource que l'OS gère. C'est même son boulot, et si tu n'es pas d'accord avec ça, va voir du côté des exo-noyaux. Pour le données d'une base de donnée, c'est effectivement le rôle de la base de donnée de gérer les autorisations. Mais l'OS a la responsabilité que personne ne puisse accéder au fichier de la base de donnée (à part la BDD elle même évidemment)
Note que je ne suis pas contre une belle API qui centralise tout ça. Mais une telle API DOIT se baser sur les services fournis par l'OS (ACL, SElinux, chroot, sudo,...). Ce ne doit pas être un bête wrapper autour de open...
> Autre exemple, le systeme de gestion de paquet de Debian gère les signatures des paquets avant d'installer un paquet.
J'ai dit: c'est le rôle de l'OS. Je n'ai pas dit: c'est le rôle du noyau
Le système de gestion de paquets fait partie de l'OS Debian GNU/Linux, et c'est effectivement son rôle de vérifier que n'importe qui ne puisse pas corrompre les programmes ou les bibliothèques partagées installés... C'est pour cela que Java WebStart est une aberration sur une distrib Linux !
> Tu nous cites l'exemple DCOP /DBUS mais comment font ils pour communiquer avec du pur CORBA ou encore du DCOM.
Où c'est dit que cette technologie apportera miraculeusement la compatibilité universelle et permanente avec tout ce qui a existé, existe et existera ?
*relis l'article*
Ha, ça y est, je viens de piger. En fait, l'API est indépendante du protocole. Bravo, c'est la définition d'une couche d'abstraction, appliquée aux divers systèmes IPC existants.
Et ? C'est ça la révolution miraculeuse qui va tout déchirer le monde des web services ?
(d'ailleurs, j'ai du mal à voir pour quoi est fait ce truc: IPC, comme dit dans l'article, ou web service (parce que j'ai vraiment du mal à voir l'intérêt d'utiliser HTTP pour de l'IPC))
C'est une idée pas mauvaise, effectivement. Mais pas de quoi hurler à la révolution. Un truc comme ça se fait en quelques jours en python par quelqu'un qui maitrise son sujet (c'est à dire sans compter le temps d'apprentissage de DCOM/DBUS/DCOP/CORBA/...)
Mais surtout: vendre ça comme un avantage de .NET (pour revenir au sujet), c'est plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)
De la même manière que les démons Unix baissent volontairement leurs privilèges, le programme demande à l'OS d'appliquer une politique de sécurité plus stricte pour le process représentant l'applet avant de la lancer
> Ca va être portable ça
Ça pourrait faire l'objet d'une couche d'abstraction dans l'API de base de .NET, là ça ne pose aucun problème. Si t'es sous Linux -> SElinux, si t'es sous Vista -> je sais pas quoi, etc...
Vraiment, oui, ça a l'air très intéressant... pour le programmeur payé à la ligne de code (pour l'employeur, moins, mais les commerciaux sont là pour le convaincre que plus c'est lourd, mieux c'est)
Après avoir lu cet article, je ne peux pas m'empêcher de citer Rich Felker:
"Piling more complexity on top of mistaken complexity is not a solution. It's pure stupidity"
Honnêtement, où est l'idée sexy là dedans ? Je ne vois qu'un moyen BEAUCOUP plus compliqué (doux euphémisme) de faire ce que DCOP/DBUS font depuis des années. Ça n'apporte rien, à part quelques buzwords à ajouter au dictionnaire (ou peut être pas en fait, mon dictionnaire de buzzwords est très vieux...)
Non, sérieusement, si tu pouvais me dire ce qu'il y a de sexy là dedans, ce serait gentil, parce que là, j'ai vraiment l'impression d'avoir loupé quelque chose...
> 1) Faire tourner une application avec le minimum de privilège possible est la base de la sécurité
Je suis d'accord :)
> Tout les bons démons unix laissent tomber leur privilège root pour s'exposer le moins possible aux attaques.
Oui, mais ils demandent ça à l'OS. Ce que je veux dire par "c'est ridicule de présenter ça comme un avantage", c'est que ce n'est pas le boulot du langage ou de la VM, mais de l'OS de contrôler si les applications ne font pas plus qu'elles ne sont autorisées...
C'est un peu comme si tu faisais un protocole applicatif qui s'occuperait du routage des paquets. C'est totalement ridicule...
> + La gestion des modules avec signature cryptologique forte.
> + La séparation des privilèges d'unappli .Net est très intéressante. Ainsi, on peut exécuter une appli en l'empêchant d'accéder aux ressources locals (disque dur, réseau...) Il est possible ainsi de sécuriser un code avec une granulométrie qui est celle d'une méthode
Et dire que certains osent mettre ça dans les avantages...
> + L'intégration et la simplicité de développement des webs services.
Rassure moi, c'était une farce ? hein ?
Je croyais que tout le monde le savait pourtant: le soleil, c'est comme une grosse étoile, donc une grosse luciole qui s'est décrochée de la toile céleste. Et une luciole ne s'éteint pas dans l'eau...
En même temps, on parle d'une constitution là. Personnellement, même si je suis *complètement* largué par l'obscurité de la loi et du droit français (je comprends mieux un programme de l'IOCCC :)), je comprends encore à peu près la constitution, et comment les institutions marchent (ou pas).
Comme il y a beaucoup de scientifiques ici, je vas prendre une analogie qui me parait tout à fait fondée: une constitution, ce devrait être un système d'axiomes. Ça doit être le plus concis et le plus simple possible, parce que c'est *la base* de tout, et tout le monde doit comprendre parfaitement et être d'accord avec chaque point. Sinon, on avancera jamais ensemble.
Au dessus de ça, effectivement, on fait des lois, des decrets plus complexes, souvent non abordables par le "citoyen lambda" (mais franchement, je ne pense pas non plus que ce soit une bonne chose).
Personnellement, je n'avais pas encore le droit de vote lors du référendum, mais j'aurais probablement voté non, pour ces raisons, et seulement ces raisons. Même si je suis pour l'europe et pour une consitution européenne. Parce qu'une constitution doit rester simple, précise, concise et compréhensible par tous.
Arrêter de voir la démocratie comme une dictature par par morceaux ? (bon, on m'a élu, donc j'ai les quasi-pleins pouvoirs pendant 5 ans, et je peux faire ce que je veux sans avoir de comptes à rendre)
C'était d'ailleurs le point principal d'un certain candidat centriste, au cas où tu hibernais pendant les présidentielles...
Ha oui, et aussi, personnellement, je cracherais pas pour une simplification de la loi, au lieu de la surenchère constante vers la complexité. Histoire que le "nul c'est censé ignorer la loi" ne soit plus un bonne blague (honnêtement, en lisant le journal de Cooker, ce qui m'a fait le plus peur n'a pas été "fichage ADN pour deux coups de fils ? WTF ?" mais plutôt "si j'avais été à sa place, je ne connais rien de mes droits/recours dans une telle situation: je n'ai pas fait 5 ans de droit...")
Faudrait que je vérifie la date, mais le lieu et le personnage correspondent...
C'est très difficile à trouver parce qu'il y a un autre Michel Conte, plus connu, mais j'ai trouvé ça: www.antigravite.org/sources/Sommaire.doc , mecanica.unitbv.ro/conferinte/compmec/pages/programme.htm et mf.unze.ba/tmt2006/final%20program%202006.pdf .
> Quand on lit certaines thèses (même dans des domaines comme la physique), on se rend compte à quel point la confiance aveugle et l'argument d'autorité sont courants.
À ce niveau, j'ai une anectode complètement surréaliste: il y a quelque mois, j'ai été à une "conférence" "Les énigmes de la physique contemporaine", faite par un prof de mon école d'ingénieur. Je ne citerai bien évidemment aucun nom, mais en substance, ça a fini en: "j'aime pas la mécanique quantique, et j'ai fait ma propre théorie que voilà: dans tout l'univers baigne une onde EM mère (de période la longueur de Planck) dont découlent la matière, la gravitation, l'énergie et les photons: ce ne sont que des harmoniques de cette onde. Cela explique notamment la lévitation humaine, l'aura et les OVNIs"
Quand j'ai vu ça, la première chose qui m'est venue à l'esprit, c'est "il a fait un pari, combien de temps il arriverait à tenir comme cela", ben non. Il a fait un site internet, publié un livre, et une conférence dans un colloque scientifique (!!!) roumain.
LE truc... surréaliste, là dedans, c'est qu'il y croit. Qu'apparament, aucun de des collègues ne lui ai rien dit (personne n'en avait le coeur peut être ;)), mais SURTOUT, que dans la 50aines d'élèves (en école d'ingénieur), on devait être 3 ou 4 à ne pas l'écouter religieusement. Quelqu'un qui a émis une objection s'est même fait rétorquer un "si ça ne t'intéresse pas, tu peux sortir" par un autre étudiant ! Sur le coup, ça fait vraiment bizarre...
Posté par Moonz .
En réponse au journal Editeur XML.
Évalué à 2.
Tu ne m'as pas compris :)
> La gratuité n'est pas nécessaire pour du peer-review ou de la contribution
Ça c'est la théorie. Alors faisons un peu de pratique.
J'ai en ce moment sur mon disque dur un logiciel super-top-moumoute de ma création. Il est sous licence GPL. Je le vends pour 300 euros à qui le demande, avec accès aux sources (puisque GPL)
Honnêtement, ça te fait une belle jambe de savoir que tu peux y contribuer et le reviewer parce qu'il est libre, puisque le prix t'inderdit de l'acheter juste pour reviewer ou pour espérer que même si le logiciel te correspond pas à 100% du peux le modifier. Ce logiciel sur mon disque dur n'aura jamais une seule contribution, et personne ne verra le code. Même s'il est libre.
C'est bien sûr exagéré et capillotracté, mais l'idée est là. Quand tu parles de contribution et de peer-reviewing, tu parles de travail communautaire. Pour ça, je persiste, la gratuité est nécessaire. Pas en stricte théorie bien évidemment, mais en pratique, si je compte acheter du LL, c'est que j'ai eu AVANT accès au logiciel et au code gratuitement, et que je sais que techniquement, il est suffisament proche de mes besoins et bien codé pour que je puisse l'adapter à mon utilisation.
Toujours personnelement, si un jour je devais m'impliquer dans le dev d'une distribution Linux, deux possibilités:
- soit un truc communautaire "just for fun"
- une distribution commerciale mais que j'ai pu tester gratuitement ET librement (et les deux sont aussi importants l'un que l'autre !) et dont je connais la valeur technique
Jamais je ne m'engagerai dans une distribution qui m'impose l'achat AVANT de pouvoir modifier ou regarder le code. Même si elle est libre.
> Tu introduis une notion de « utilisateur bénévole »
J'admets que j'ai pas été clair sur ce coup. C'était juste pour introduire la différence entre l'étudiant passionné et la grosse entreprises. Les deux n'ont certainement pas la même approche envers un logiciel libre et payant, et je me place dans le premier cas (le mien). C'est tout ce que je voulais dire par là...
Posté par Moonz .
En réponse au journal Editeur XML.
Évalué à 5.
Mais dans le cas d'un utilisateur bénévole, la gratuité est nécessaire pour des choses comme le possibilité de contribuer/améliorer ou le peer-reviewing. Donc pour moi (en tant que non professionnel) effectivement la gratuité est une caractéristique fondamentale (dans le sens condition nécessaire mais non suffisante) du logiciel libre.
Ce que je voulais dire: ceux qui croient que France <=> président de la République, je me *contrefous* de ce qu'ils peuvent penser de la France. Ceux qui ont un minimum d'esprit critique sauront faire la différence. Les autres n'ont pas attendu Sarkozy pour avoir des préjugés à la con...
Je trouve aussi dommage de baser un truc libre comme ça sur des formats proprios à la ***. FFmpeg ou Gstreamer n'auraient pas pu faire l'affaire ?
* jette un rapide coup d'oeil aux sources *
En dehors de ça, je trouve les 5 dernières lignes de ftpstream.py particulièrement tarabiscottées :) (et c'est quoi ce +30+6 à headerSize ?)
Mais effectivement, AMHA ça devrait vraiment pas être difficile à adapter à un format libre.
Et en plus, je pense que toute la partie acquisition/encodage/ftpstream pourrait se faire facilement à l'aide d'une chaine gstreamer avec l'aide de gnome-vfs, genre:
gst-launch v4l2src ! ffmpegcolorspace ! theoraenc ! oggmux ! gnomevfssink location=ftp://user:password@server/stream.ogg
Yapuka :p
Très honnêtement, si tu te contentes de balancer un ou deux exemples avec quelques explications sur internet, ça me semble suffisament intéressant pour que quelqu'un s'y penche de plus près...
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 3.
Comment fait HTTP, selon toi ? C'est écrit en dur dans la RFC 2616 ?
Ce que je voulais dire par "SSH" c'est pas "on fait un hack quick & dirty" mais "on peut faire sans complexifier la spec"
> Moi je prends un framework quelconque, style Java ou .NET, non y'a rien pour consommer un service DBus de base, et pourtant ces framework en implémente des standards
Standard = implémenté dans Java/.NET
C'est sûr qu'avec des définitions comme ça, y'aura pas grand chose de standard :)
> C'est pas REST mais c'est non plus très loin.
Mais c'est qu'il récidive, le bougre :)
SOAP se traine vaguement au dessus d'un protocole de type REST comme un boulet au pied pour des raisons pratiques (HTTP, ça passe partout). La comparaison s'arrête là. SOAP, c'est du RPC, l'opposé de REST (dans les longs trolls du moins :p)
> Si on avait gardé la philosophie Unix, on communiquerait qu'avec des pipes entre petits composants en ligne de commande hein ;)
De la différence entre le fond et la forme...
> Ca c'est les types de base, mais si on veut représenter par exemple
> une date
timestamp ? RFC 822 ?
Encore une fois, tu crois qu'ils font comment, pour HTTP ? Ils définissent un type date, ou ils disent simplement "une date sera formatée comme défini dans la RFC xxx ou yyy, au choix. Toute autre date est indéfinie"
> Un type énuméré ?
Tu parles des "enum" du C ? un entier suffit largement...
> Une url ?
Comme tout le monde, par une chaine de caractères ?
> Y'a quoi pour spécifier de nouvaux formats ?
> Si je veux réstreindre un entier à certaines valeurs ? à un minimum à un maximum ?
C'est cette surenchère à la complexité, justement, qui ne me plait pas.
> Bref si je veux spécifier de manière précise les données qui transite de manière formelle et standard ?
C'est si difficile que ça de se mettre d'accord entre devs ? (dans la doc technique, à tout hasard)
Est-ce vraiment nécessaire d'over-bloater une spec déjà alourdie par: les 397 moyens de passer par HTTP GET, HTTP POST, HTTP PUT, HTTP DELETE, FTP, SMTP, IPoT, l'authentification, la cryptholographie, la numérologie, la redundanc-scalability, 965 définitions de type (URL, Date, Path, Port, Range, Domain, User, Password, Service, ServiceInfo, ServiceInfoServer, ServiceInfoServerInfo, Toto, Tata, Tutu, Titi, Rominet) juste pour ça ?
> faut pas réinventer la roue, mais faut standardiser ca dans DBus.
Non. Enfin, par les types de DBus, oui, mais pas dans la spec de DBus elle même.
> Et là encore une fois, c'est toi qui a décidé de StartTransact et EndTransact : quand tout le monde aura comme toi réinventer la roue pour mettrte en oeuvre des opération atomiques à partir de plusieurs échanges de messages, certains vont se dire "et si on standardisait ca ?"
On peut le standardiser de la même manière que l'introspection...
Et l'implémenter de la même manière...
> c'est lié à d'autres problème : l'utiliation de standards verbeux entre autre.
Non, c'est lié à la surcomplexification.
XML-RPC, du temps ou je l'ai vu, avait une spec de deux pages. Il ne nécessitait aucun outillage étrange de génération d'interfaces qui lui même génère des source qui génèrent..., et était entièrement implémentable en moins d'une journée avec l'aide d'une bonne lib XML
Dis moi, la spec de SOAP: combien de pages ? Pourrais tu t'en sortir sans la grosse artillerie d'IDEs, d'aides au dévellopement, d'aide aux outils de dev, d'aide aux outils d'aides aux outils de dev... ? Combien de temps pour implémenter complètement les specs (même de manière quick & dirty) ? Pour quel apport, finalement, par rapport à XML-RPC ?
Pour finir, même si tu as des outils qui te cachent la saleté sous le tapis, qu'est-ce que tu fais quand ils te lachent ? Si tu veux les débugger ?
Le but, c'est de pisser du code sans vraiment comprendre ce qui se passe en interne ou de faire quelque chose de relativement sûr qui ne donne pas de surprises ?
Si demain, ton application se met à merder après recompilation alors que tu n'as modifié que les commentaires, tu accuses qui ? Ton code ? Ou une des 360000 lignes autogénérées ? Si c'est le deuxième cas, tu fais comment pour corriger le problème (à part prier) ?
Ce n'est pas parce que ça "parait" simple que "c'est" simple. Cacher la complexité derrière du code auto généré, c'est un peu comme la politique de l'autruche, ça ne résoud pas les vrais problèmes.
C'est de ce juste milieu que je parlais. Effectivement, c'est plus contre SOAP que contre WCF, je te l'accorde ;)
> SOAP fait une seule chose et le fait bien : définir un format de définition d'échange de message.
Non. SOAP permet de faire
- du passage de messages
- de définition de messages
- de validation de messages
- plus l'authentification, le cryptage et tous les trucs dont tu vantes les mérites
Avec chacun de ces points tellement complexe qu'il meriterait une spec à lui seul.
Faire une seule chose, c'est faire une seule chose simple, sinon c'est qu'on pouvait décomposer la chose en sous problèmes indépendants. C'est visiblement le cas de SOAP (pas de WCF, je te l'accorde, mais cf une citation précédente: "piling complexity...")
> C'est d'ailleur sans doute la première raison pour laquelle DBus n'utilise pas XML dans des messages textes par exemples : ils auraient pu s'appuyer sur l'existant mais pour des questions de perfs inter-process, rien ne vaut protocole optimisé pour les besoins que l'ont tente d'adresser.
Tu es de ceux qui pensent que HTTP devrait être réécrit en XML ?
Faut pas déconner, XML n'est pas LA solution universelle. Même s'il est adapté dans la très grande majorité des cas, la non utilisation de XML n'est pas forcément un pis-aller. SMTP, HTTP & co se basent sur l'existant: l'ASCII. C'est largement suffisant pour leur besoin, pourquoi chercher plus loin ? Pour avoir le plaisir de dire "yeah, moi je suis xml-compliant" ?
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 7.
Et j'ai dit que l'API de dbus/python était aussi souple et plus simple, donc plus "sexy" à mon gout (et j'ai admis que ça WFC pouvait aussi être vu comme sexy par ceux qui n'ont connu que SOAP et les DCOM/CORBA).
C'est bien beau ce gros pâté, mais dbus, c'est de l'IPC, pas du web service :) (ne mélangeons pas les torchons et les serviettes). J'aimerais seulement réagir sur quelque points, je ne peux pas te maisser dire de telles choses sur DBus...
> - comment je gère le cryptage de mes services de manière standards ?
tunneling SSH ?
> Je dois me coltiner un format qui n'a rien de standard ?
Les spécifications du protocole de DBUS sont gardées secrètes ? On m'aurait menti ?
Et pour WCF, seule l'API est peut être standard, j'en sais rien. Mais tu peux implémenter un protocole non standard au dessus de ça, donc bon...
> Même si ca ne respecte pas le protocole HTTP pour ce qu'il a été conçu, les web-services utilisent le même principe extrêment simple de client qui demande une ressource qu'expose un serveur (architecture REST).
Rassure moi, tu t'es mal exprimé, hein ?
Parce que tu dois être la seule personne sur internet à dire que les web services de type SOAP ont une architecture REST...
> Les web-services répondent à une problématique bien précise : l'inter-opérabilité
Alors là, faut que tu m'expliques comment les web services répondent mieux à cette problématique que dbus. Un protocole de web service est intéropérable avec... lui même. Comme dbus.
> DBus c'est de l'événementiel ultra-simple.
DBus n'est pas uniquement événementiel. Il peut être utilisé comme ça (cf HAL), mais ce n'est pas obligatoire (ce que KDE va en faire, en gros)
> Simple parcque tout jeune.
Non. DBus n'est déjà plus tout jeune. Il est simple parce qu'il est VOULU simple. Unix. KISS. Tout ce que les programmeurs Java/C# ont oubliés depuis longtemps, quoi (troll inside, don't feed the troll :p)
> Demain ils vont vouloir exposer des services à travers internet
À moins que tu n'assassines deux trois développeurs pour prendre leur place, il y a peu de chances
> toute les couches d'abstraction qui vont bien
Trop d'abstraction tue la simplicité, l'efficacité et au final même la souplesse fini pa en pâtir. À faire trop d'abstractions, on en finit par oublier les problèmes réels.
Les devs de DBus pensent avoir atteint le juste milieu, donc cf remarque précédente
> ils vont vouloir ajouter de l'introspection
Ça existe déjà. De manière SIMPLE et efficace
> ils vont chercher à standardiser la façon d'échanger certains types de données
cf remarques précédentes. Encore une fois, tu as l'air de penser que les problèmes complexes nécessitent des solutions complexes. C'est complètement faux. Dans la plupart des cas, simplicité implique souplesse, et la souplesse permet de régler simplement des problèmes complexes.
Actuellement, tout peut être représenté avec DBus (il y a les nombres (de différents types)), les chaines de caractères, les tableaux, les structures et les tableaux associatifs. Qu'est ce qui ne peut pas être construit à partir de ça ?
> les normes de cryptage
SSH. Pourquoi réinventer la roue, crévindiou ?
> d'authentification
Tu n'as visiblement pas compris quels étaient les buts de DBus
L'authentification DBus, c'est l'authentification de l'utilisateur Unix. Pas la peine de chercher midi à quatorze heures pour ça
> de transaction
Je vois pas ce que tu veux dire là dedans... Dans le même sens que les transactions des BDD ? Où est la difficulté de faire une méthode StartTransact et une méthode EndTransact ?
> DBus va rester super simple et le developpeur sera contraint de réinventer la roue, de manière non standard, buggé et non éprouvé.
C'est LE point central.
Toute l'histoire des web services, ça a été "on met tout dans le protocole afin de simplifier la vie au programmeur". Au final, ça a donné les monstres de complexité que l'on connait.
L'approche DBus, AMHA, est beaucoup plus saine: le protocole reste SIMPLE, il ne fait qu'UNE chose, et il le fait BIEN. Si ensuite, on voit qu'il y a des besoins communs à tous les utilisateurs, alors on fait une bibliothèque partagée "dbus-utils" qui s'en occupe. C'est par exemple le cas de l'introspection. Les specs du protocole n'en parlent même pas. À la place, tu as des fonctions pour l'introspection dans les libs et un document séparé disant que "l'introspection se fait par l'intermédiaire de org.freedesktop.DBus.Introspectable.Introspect dont voici les paramètres et ce que ça doit donner en sortie". De la même manière, les propriétés sont gérées par une interface org.freedesktop.DBus.Properties. Que tu ne trouveras jamais dans les specs
du protocole, parce que son boulot, c'est JUSTE du RPC.
C'est ça la souplesse et la modularité. C'est autre chose que les montagnes d'abstractions qu'on voit dans le monde Java/.NET
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 2.
Mais tout dépend du référentiel :) (et c'est pour ça qu'on est pas d'accord, AMHA)
Comparé à ce que j'ai ouïe dire des SOAP, CORBA, DCOM & co, effectivement, c'est beaucoup plus simple et quelqu'un qui ne connaitrait que ça pourrait sincèrement dire "c'est vraiment sympa et sexy"
Mais comparé au couple dbus/python (ou dbus/quoi que ce soit d'autre, ne soyons pas sectaires), ça n'apporte rien de concrètement intéressant, surtout pour la complexité apportée (je le répète, relativement à dbus). Et je ne trouve pas ça sexy.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 4.
Ce qui me dérange, c'est qu'on commence à faire une énorme couche d'abstraction bien lourde juste pour le plaisir, sans qu'il y ait de réel besoin pour ça
Alors qu'une couche mince et simple aurait fait l'affaire
C'est à dire l'opposé complet des conseils de bonne programmation unix
Mais c'est dans la continuité des .NET, C#, Java & co après tout :)
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 3.
Après, faut voir avec quoi tu compares. Si tu compares avec les anciennes technologies proprios de ce type, je n'en sais rien, je connais pas. Si tu compares à DBUS, ça n'apporte vraiment rien.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 3.
Effectivement, parce que le formulaire administratif n'est pas une ressource que l'OS gère
Mais moi, je répondais à:
>> accède à des fichiers auxquel je ne souhaite pas l'autoriser ou qui seraient sensibles.
Et les fichiers, c'est une ressource que l'OS gère. C'est même son boulot, et si tu n'es pas d'accord avec ça, va voir du côté des exo-noyaux. Pour le données d'une base de donnée, c'est effectivement le rôle de la base de donnée de gérer les autorisations. Mais l'OS a la responsabilité que personne ne puisse accéder au fichier de la base de donnée (à part la BDD elle même évidemment)
Note que je ne suis pas contre une belle API qui centralise tout ça. Mais une telle API DOIT se baser sur les services fournis par l'OS (ACL, SElinux, chroot, sudo,...). Ce ne doit pas être un bête wrapper autour de open...
> Autre exemple, le systeme de gestion de paquet de Debian gère les signatures des paquets avant d'installer un paquet.
J'ai dit: c'est le rôle de l'OS. Je n'ai pas dit: c'est le rôle du noyau
Le système de gestion de paquets fait partie de l'OS Debian GNU/Linux, et c'est effectivement son rôle de vérifier que n'importe qui ne puisse pas corrompre les programmes ou les bibliothèques partagées installés... C'est pour cela que Java WebStart est une aberration sur une distrib Linux !
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 4.
Où c'est dit que cette technologie apportera miraculeusement la compatibilité universelle et permanente avec tout ce qui a existé, existe et existera ?
*relis l'article*
Ha, ça y est, je viens de piger. En fait, l'API est indépendante du protocole. Bravo, c'est la définition d'une couche d'abstraction, appliquée aux divers systèmes IPC existants.
Et ? C'est ça la révolution miraculeuse qui va tout déchirer le monde des web services ?
(d'ailleurs, j'ai du mal à voir pour quoi est fait ce truc: IPC, comme dit dans l'article, ou web service (parce que j'ai vraiment du mal à voir l'intérêt d'utiliser HTTP pour de l'IPC))
C'est une idée pas mauvaise, effectivement. Mais pas de quoi hurler à la révolution. Un truc comme ça se fait en quelques jours en python par quelqu'un qui maitrise son sujet (c'est à dire sans compter le temps d'apprentissage de DCOM/DBUS/DCOP/CORBA/...)
Mais surtout: vendre ça comme un avantage de .NET (pour revenir au sujet), c'est plutot de mauvaise foi pour une technologie qui se veut intéropérable avec le reste du monde :)
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 3.
> Ca va être portable ça
Ça pourrait faire l'objet d'une couche d'abstraction dans l'API de base de .NET, là ça ne pose aucun problème. Si t'es sous Linux -> SElinux, si t'es sous Vista -> je sais pas quoi, etc...
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 6.
Vraiment, oui, ça a l'air très intéressant... pour le programmeur payé à la ligne de code (pour l'employeur, moins, mais les commerciaux sont là pour le convaincre que plus c'est lourd, mieux c'est)
Après avoir lu cet article, je ne peux pas m'empêcher de citer Rich Felker:
"Piling more complexity on top of mistaken complexity is not a solution. It's pure stupidity"
Honnêtement, où est l'idée sexy là dedans ? Je ne vois qu'un moyen BEAUCOUP plus compliqué (doux euphémisme) de faire ce que DCOP/DBUS font depuis des années. Ça n'apporte rien, à part quelques buzwords à ajouter au dictionnaire (ou peut être pas en fait, mon dictionnaire de buzzwords est très vieux...)
Non, sérieusement, si tu pouvais me dire ce qu'il y a de sexy là dedans, ce serait gentil, parce que là, j'ai vraiment l'impression d'avoir loupé quelque chose...
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 5.
Je suis d'accord :)
> Tout les bons démons unix laissent tomber leur privilège root pour s'exposer le moins possible aux attaques.
Oui, mais ils demandent ça à l'OS. Ce que je veux dire par "c'est ridicule de présenter ça comme un avantage", c'est que ce n'est pas le boulot du langage ou de la VM, mais de l'OS de contrôler si les applications ne font pas plus qu'elles ne sont autorisées...
C'est un peu comme si tu faisais un protocole applicatif qui s'occuperait du routage des paquets. C'est totalement ridicule...
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 4.
[^] # Re: Microsoft comprend enfin l'intérêt du Libre
Posté par Moonz . En réponse à la dépêche Miguel de Icaza fait une démonstration de Moonlight. Évalué à 2.
> + La séparation des privilèges d'unappli .Net est très intéressante. Ainsi, on peut exécuter une appli en l'empêchant d'accéder aux ressources locals (disque dur, réseau...) Il est possible ainsi de sécuriser un code avec une granulométrie qui est celle d'une méthode
Et dire que certains osent mettre ça dans les avantages...
> + L'intégration et la simplicité de développement des webs services.
Rassure moi, c'était une farce ? hein ?
[^] # Re: euh...
Posté par Moonz . En réponse au journal Mono est mort. Évalué à 2.
[^] # Re: c'est bien connu
Posté par Moonz . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 3.
[^] # Re: Je mets les pieds dans le plat et j'en fous partout
Posté par Moonz . En réponse au journal Traité sur le fonctionnement de l'Union. Évalué à 2.
Comme il y a beaucoup de scientifiques ici, je vas prendre une analogie qui me parait tout à fait fondée: une constitution, ce devrait être un système d'axiomes. Ça doit être le plus concis et le plus simple possible, parce que c'est *la base* de tout, et tout le monde doit comprendre parfaitement et être d'accord avec chaque point. Sinon, on avancera jamais ensemble.
Au dessus de ça, effectivement, on fait des lois, des decrets plus complexes, souvent non abordables par le "citoyen lambda" (mais franchement, je ne pense pas non plus que ce soit une bonne chose).
Personnellement, je n'avais pas encore le droit de vote lors du référendum, mais j'aurais probablement voté non, pour ces raisons, et seulement ces raisons. Même si je suis pour l'europe et pour une consitution européenne. Parce qu'une constitution doit rester simple, précise, concise et compréhensible par tous.
[^] # Re: à la différence de la fois précédente
Posté par Moonz . En réponse au journal Traité sur le fonctionnement de l'Union. Évalué à 2.
C'était d'ailleurs le point principal d'un certain candidat centriste, au cas où tu hibernais pendant les présidentielles...
Ha oui, et aussi, personnellement, je cracherais pas pour une simplification de la loi, au lieu de la surenchère constante vers la complexité. Histoire que le "nul c'est censé ignorer la loi" ne soit plus un bonne blague (honnêtement, en lisant le journal de Cooker, ce qui m'a fait le plus peur n'a pas été "fichage ADN pour deux coups de fils ? WTF ?" mais plutôt "si j'avais été à sa place, je ne connais rien de mes droits/recours dans une telle situation: je n'ai pas fait 5 ans de droit...")
[^] # Re: De la bonne utilisation de Wikipédia dans l'éducation
Posté par Moonz . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 2.
C'est très difficile à trouver parce qu'il y a un autre Michel Conte, plus connu, mais j'ai trouvé ça: www.antigravite.org/sources/Sommaire.doc , mecanica.unitbv.ro/conferinte/compmec/pages/programme.htm et mf.unze.ba/tmt2006/final%20program%202006.pdf .
[^] # Re: De la bonne utilisation de Wikipédia dans l'éducation
Posté par Moonz . En réponse au journal Wikipedia encoe attaqué dans l'éducation. Évalué à 3.
À ce niveau, j'ai une anectode complètement surréaliste: il y a quelque mois, j'ai été à une "conférence" "Les énigmes de la physique contemporaine", faite par un prof de mon école d'ingénieur. Je ne citerai bien évidemment aucun nom, mais en substance, ça a fini en: "j'aime pas la mécanique quantique, et j'ai fait ma propre théorie que voilà: dans tout l'univers baigne une onde EM mère (de période la longueur de Planck) dont découlent la matière, la gravitation, l'énergie et les photons: ce ne sont que des harmoniques de cette onde. Cela explique notamment la lévitation humaine, l'aura et les OVNIs"
Quand j'ai vu ça, la première chose qui m'est venue à l'esprit, c'est "il a fait un pari, combien de temps il arriverait à tenir comme cela", ben non. Il a fait un site internet, publié un livre, et une conférence dans un colloque scientifique (!!!) roumain.
LE truc... surréaliste, là dedans, c'est qu'il y croit. Qu'apparament, aucun de des collègues ne lui ai rien dit (personne n'en avait le coeur peut être ;)), mais SURTOUT, que dans la 50aines d'élèves (en école d'ingénieur), on devait être 3 ou 4 à ne pas l'écouter religieusement. Quelqu'un qui a émis une objection s'est même fait rétorquer un "si ça ne t'intéresse pas, tu peux sortir" par un autre étudiant ! Sur le coup, ça fait vraiment bizarre...
[^] # Re: Mpfff...
Posté par Moonz . En réponse au journal Editeur XML. Évalué à 2.
> La gratuité n'est pas nécessaire pour du peer-review ou de la contribution
Ça c'est la théorie. Alors faisons un peu de pratique.
J'ai en ce moment sur mon disque dur un logiciel super-top-moumoute de ma création. Il est sous licence GPL. Je le vends pour 300 euros à qui le demande, avec accès aux sources (puisque GPL)
Honnêtement, ça te fait une belle jambe de savoir que tu peux y contribuer et le reviewer parce qu'il est libre, puisque le prix t'inderdit de l'acheter juste pour reviewer ou pour espérer que même si le logiciel te correspond pas à 100% du peux le modifier. Ce logiciel sur mon disque dur n'aura jamais une seule contribution, et personne ne verra le code. Même s'il est libre.
C'est bien sûr exagéré et capillotracté, mais l'idée est là. Quand tu parles de contribution et de peer-reviewing, tu parles de travail communautaire. Pour ça, je persiste, la gratuité est nécessaire. Pas en stricte théorie bien évidemment, mais en pratique, si je compte acheter du LL, c'est que j'ai eu AVANT accès au logiciel et au code gratuitement, et que je sais que techniquement, il est suffisament proche de mes besoins et bien codé pour que je puisse l'adapter à mon utilisation.
Toujours personnelement, si un jour je devais m'impliquer dans le dev d'une distribution Linux, deux possibilités:
- soit un truc communautaire "just for fun"
- une distribution commerciale mais que j'ai pu tester gratuitement ET librement (et les deux sont aussi importants l'un que l'autre !) et dont je connais la valeur technique
Jamais je ne m'engagerai dans une distribution qui m'impose l'achat AVANT de pouvoir modifier ou regarder le code. Même si elle est libre.
> Tu introduis une notion de « utilisateur bénévole »
J'admets que j'ai pas été clair sur ce coup. C'était juste pour introduire la différence entre l'étudiant passionné et la grosse entreprises. Les deux n'ont certainement pas la même approche envers un logiciel libre et payant, et je me place dans le premier cas (le mien). C'est tout ce que je voulais dire par là...
[^] # Re: Mpfff...
Posté par Moonz . En réponse au journal Editeur XML. Évalué à 5.
[^] # Re: amha
Posté par Moonz . En réponse au journal Arrêt d'arrêt. Évalué à 3.
[^] # Re: amha
Posté par Moonz . En réponse au journal Arrêt d'arrêt. Évalué à 0.
[^] # Re: Comme promis...
Posté par Moonz . En réponse au journal Diffusion de vidéo en direct (FTP Streaming). Évalué à 3.
* jette un rapide coup d'oeil aux sources *
En dehors de ça, je trouve les 5 dernières lignes de ftpstream.py particulièrement tarabiscottées :) (et c'est quoi ce +30+6 à headerSize ?)
Mais effectivement, AMHA ça devrait vraiment pas être difficile à adapter à un format libre.
Et en plus, je pense que toute la partie acquisition/encodage/ftpstream pourrait se faire facilement à l'aide d'une chaine gstreamer avec l'aide de gnome-vfs, genre:
gst-launch v4l2src ! ffmpegcolorspace ! theoraenc ! oggmux ! gnomevfssink location=ftp://user:password@server/stream.ogg
Yapuka :p
[^] # Re: Mwais...
Posté par Moonz . En réponse à la dépêche GNU Affero General Public License : la GPL des applications web. Évalué à 8.
[^] # Re: Autres grammaires
Posté par Moonz . En réponse au journal L'expressivité des langages. Évalué à 2.