Moonz a écrit 3537 commentaires

Mais voilà la version Python:

import sys

input = sys.stdin.read()

i = "0"
for line in input.splitlines():
	if "->" in line:
		i = line.split("->")[0]
	elif ';' in line:
		for j in line.split(";"):
			if j.strip():
				print "%s->%s"% (i, j)
	else:
		print line

Ce qui confirmele théorème du " pourquoi un homme ne peut être beau et intelligent à la fois ?"
Oui, je sais, --->[]

Bon, je viens de faire (rapidement, avec des hacks de partout) fonctionner mudur et çomar sur ma gentoo, et je suis plutôt... mitigé
D'un côté, mudur est tout simplement génial. Faire tenir toute la séquence de boot sur ~1000 lignes de code claires comme de l'eau de roche, chapeau bas. Je l'ai adopté :)
Par contre, çomar est plutôt... décevant. Plus complexe quoi. Ça donne vraiment l'impression de sortir l'artillierie lourde pour pas grand chose :)
En résumé, mon projet pour la semaine à venir sera:
- adapter joliment mudur pour ma gentoo. Ça vaut franchement le coup :=)
- me coder rapidement un remplaçant de çomar. Un truc simple et sans fioritures ;)

te permet de faire du refactoring en 2 coups de cuillère à pot, te permet de faire de la modélisation ou de créer des clients métiers (RCP) qui offrent des vues graphiques (Gantt, camemberts, ...) grâce à GMF, de la génération de code et du MDD à gogo,.....

Choses déjà beaucoup moins utiles quand on code dans un langage fait pour être écrit par un être humain et non pas géré par un IDE...

Apparement, Xiph ne compte plus faire &voluer Vorbis mais plutôt se concentrer sur un nouveau codec [http://wiki.xiph.org/index.php/Ghost]

dlfp, tu l'aimes ou tu le quittes :)

> la bonne habitude de lire des docs et d'apprendre à utiliser un système.
C'est donc un truc de geek. Pas la peine de se cacher derrère des "oui, mais..."
Un truc de geek n'est pas (forcément) un truc inutilisable, hein :)

Je m'y suis mis il y a quelque mois, c'est un vrai plaisir. C'est le chainon manquant (et nécessaire) entre C et Python :). C'est un peu difficile de s'y mettre (le plus dur étant de loin de retenir les conventions pour la gestion de la mémoire...), mais honnêtement, je pense que ça vaut le coup
Le seul problème (et de taille !), c'est qu'il n'y a aucune lib sympa pour faire des interfaces graphiques utilisables (non, gnustep-gui n'est pas utilisable quotidiennement dans un environnement "standard" (composé d'apps en XUL/GTK/Qt/Fox/FLTK/Tk/...)) et intégrées. Je ne parle pas seulement du thème par défaut - ça se change - , ni des menus - on doit pouvoir s'y faire au bout d'un moment - mais de vraiment TOUT. Le moindre élément d'une interface GNUstep est horripilant dans autre chose que du WindowMaker. L'image pour le dock qui se fout sur la barre des taches, les menus déroulants qui parfois rajoutent un élément dans la barre des tâches, les éléments qui emmêlent les pinceaux du WM pour le focus...
Juste pour m'amuser (et si ça marche il y a des chances que je finisse par l'utiliser, mais comme il y a peu de chances que ça finisse par marcher...), je suis en train d'essayer de coder des bindings GTK qui suivent l'API graphique d'OpenStep. Mais si j'échoue, je suis bien décidé à reprendre GTKKit [http://ftp.gnome.org/pub/gimp/gtk/objc-gtkkit/] :)

> Il a fallu que j'utilise g++ pour comprendre...
Tu es en train de dire qu'il y a plus illisible, tarabiscotté, incompréhensible, cryptique que les message d'erreur de g++ ?
La fin du monde est proche

ou les bots

> Partant de là, le modèle vue controleur, la séparation entre l'habillage et l'intelligence, toussa, c'est un peu loin.

Il faut écrire un moteur de template en ~templeet :)

Pour les ignares qui ont abandonné emacs quand on leur a dit "lisp", qu'a t-il de si merveilleux ce système d'indentation ? (moi, j'ai surtout ouïe dire qu'Emacs se démerde très mal avec les tabulations)

Epiphany ? Konqueror ? Opera ? Kazehakase ? Minimo ? Dillo ? Links ? Lynx ? Mantella ? Skipstone ? Atlantis ? osb-browser ? Midori ?

Pitié, pas de Flash. C'est lourd, ça met du temps à démarrer, ca plante une fois sur 2 et c'est pire que du Java.

On est en plein dans la mode du "je fais mon site tout en Flash" c'est très très chiant.

Alors le flash, oui, mais pas sur le web.

Imaginez un moment l'horreur. Toutes les pages web remplacées par des animations flash. [:fear]

Imaginez le temps de chargments des pages, la partoche de swap qui déborde, les enfants qui hurlent de douleur. Les processeurs qui fondent lorsque quelqu'un aura le malheur de charger un page style yahoo.fr

Bon, je vais m'arrêter là, parce que visiblement on sera jamais d'accord et j'ai vraiment pas le temps de troller dans le vide (même si j'aimerais bien ;)). Je tiens juste à rapporter une "blague" trouvée sur un blog:

Most standards go like this:
1. Solve 80% of the problem in a matter of weeks.
2. Spend two years arguing about the last 20%.
3. Implement the 80% in a matter of weeks. Wonder why everything is so hard.
4. Spend months implementing the last 20%. Realize why the first 80% was so hard. Curse a lot.
5. Discover that the last 20% wasn’t really worth all the time spent arguing about it or implementing it.

Pour ma part, </troll>

> 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...

J'ai peur de me répéter: c'est une blague ?

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...