Moonz a écrit 3621 commentaires

En maths, il est interdit de faire un équivalent avec 0 (même si les physiciens se gênent pas)

La deuxième ?

Parce que le monsieur de parle de propriété intellectuelle. Une voiture, c'est une création de l'esprit maintenant ?

> Bref, malheureusement, c'est pour moi l'argument facile et totalement hypothétique, et aucunement vérifiable
Je veux pas faire ma mauvaise langue, mais http://fr.wikipedia.org/wiki/Embrace%2C_extend_and_extinguis(...)

> Si y'avais pas eu les logiciels propriétaires, y'aurait jamais eu Youtube
C'est vrai, c'est bien connu que l'innovation dans le ouaib 0.2, c'est chasse gardée des logiciels propriétaires. Regarde les blogs, per exemple... ha bah non, tiens...

> ni découvrir Kamini
Personnellement, je ne m'en porte pas plus mal :p

> Contrairement à la moitié de la liste des OS que tu cites...
Ha, non, pas la moitié si tu transformes *BSD en OpenBSD, NetBSD, FreeBSD, DragonFlyBSD, MidnightBSD,...

> autant l'OO me semble apporter beaucoup de complexité pour un gain relativement faible.
Un article plutôt intéressant: http://www.etoile-project.org/etoile/blog/2007/07/road-to-co(...)
C'est quelque chose AMHA difficilement réalisable en procédural (et certainement pas élégamment)

> Au final un champion de football [...] se retrouve en prison
Ça s'appelle faire de la prévention. On devrait faire la même chose chez nous :)

Il y a une astuce sur linuxfr pour ça :)
http://linuxfr.org/tips/151.html

Pas assez marrant, on veut une expression régulière en une ligne ;)
(oui, je suis dessus depuis 1 heure maintenant ;))

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" ?