golum a écrit 2289 commentaires

Si elle investit massivement dans le spam , la démago et les liens sponsorisé sous Google oui, si elle s'en tient à un programme non

Tout a fait (cf. mon post un peu plus haut) sauf que les 2 ont tendance à converger, le coté séducteur de l'interactivité et de la simplicité avec celui de la robustesse et de l'evolutivité.

Au lieu d'apprendre les options de la ligne de commande tu consultes l'API de l'objet concerné.

Comme posté plus bas ce n'est pas la ligne de commande qui est remise en cause (cf. MSH et mon post) un peu plus bas) mais le principe de l'emboîtement des traitements sur le principe des pipes et des chaines de caractères.

Un IHM , ca évolue beaucoup plus rapidement qu'un API et ca peut être déstabilisant pour l'utilisateur comme pour le développeur qui programmerait par envoi de message directement à l'IHM. Dans un programme bien conçu, l'interface en ligne de commande n'est qu'un moyen d'exposer l'API parmi d'autres.

Aujourd'hui les langages de script ou (Python, perl, Ruby ) permettent d'être beaucoup plus productifs pour les traitement automatisables et sont surtout plus évolutifs

Les exemples de réécriture de hacks en shell qui devenaient inmaintenables réécrit dans un langage
sont nombreux (CVS, Arch, ....pour le domaine que je connais un peu)
Avec ce genre de langages il n'y a plus de réécriture, ils sont "scalables" (pas trouvé l'équivalent francais désolé) et permettent de lier facilement les parties sensibles avec du code optimisé de plus bas niveau sans tout réécrire
Ce n'est pas pour rien qu'on voit emerger de plus en plus de solution de ce genre (Ubuntu basé sur python, google qui en fait un usage intensif, et les perliens et au rubymen sauront completer la liste)

A terme on en n'arrive à ne plus distinguer les langages de scripts et les shells (cf. MSH, ipython, ....) car on prend le meileur des 2 mondes.

juste une petite précision sans importance:

Doux euphémisme :)

Trop tard les trolls sont lâchés, Garez vous !

Euh, sauf que DCOP permet de renvoyer des données, pas de les traiter...

Evidemment les données tu les traites dans ton programme et si tu veux réutiliser tu en fais un module pas un programme avec un interface en ligne de commande (sur lequele le monde unix n'a jamais cf. les variation autour de getopt)? tu publie son API et tu fournis un interface graphique..

Pour Windows , oui y'a WMI (c'etait à ca que je pensais en fait)

La ligne de commande est amnmbigue dans les shells unix , car tu n'a pas de traitement d'exception, pas d'interface stabilisée, aucun typage, ....

Le perl j'en mange régulièrement ainsi que du bash parce et je peux dire que c'est anti-productif , oui.

En fait, la ligne de commande est utile (voir Msh) ce que je critique c'est le principe des pipe et le fait qu'on ne fait que du tratement de chaine de carctères pas de données avec les shells unix

La ligne de commande te donne directement accès à de la programmation,

Tu parles d'une programmation, celle où il faut parser la sortie, et la rediriger. Celle où on crée tout un tas de programme qui ne servent quà ce genre d'usage (cut, xargs et autres hérésies) pour pallier la syntaxe et ce au détriment des perfs. Celle où le moindre contrôle des arguments ou le traitement des exceptions est un chemin de croix et reste ambigu.Celle où le moindre changement de formatage de sortie engendre tout un tas d'anomalies.

Avec des environnements graphiques, tu as bien souvent un bus de programmation qui te donne accès à la "vraie" programmation, ... structurée, réutilisable. KDE a son DCOP, Gnome son DBUS et Windows que tu critiques son COM/DCOM et même un langage shell orienté traiteme d'objet.
Mais c'est sûr il ne faut pas remettre en cause le sacro saint principe d'unix (faire une chose et le faire bien).
Pourtant appeler du DCOP est aussi simple qu'une infâme bidouille pleine de signes cabalistique illisibles en bash et peremt auatnt d'automatisation des traitements et de souplesse.

2x mignatures , ce n'est pas une faute de frappe.
Désolé je corrige, on écrit miniature comme mini pas comme signature

en laisse visiblement perplexe plus d'un.

Pourtant, ta réflexion (hormis la pub pour ton blog) sur le remplacement du protocole SMTP est intéressante. Je n'avais jamais vu ca sous cet angle, mais c'est vrai que Jabber a tout pour faire passer le cap, ... sauf des clients à la hauteur et des utilisateurs. Quand est-ce que je peux faire pointer mon Thunderbird pour aller récuperer mes messages sur mon serveur Jabber.

Sinon ca va être quoi la grande révolution Jabber de 2006 , tu peux nous en dire plus sur tes vision , Ô sérénissime orâcle !

Ouais, ca sent la boite qui voit débarquer un concurrent écrasant sur ses plate bandes et qui met son soft en OpenSource pour ne pas se faire écraser au niveau de parts de marché et qui comptant sur le relais la communauté pour elargir sa base d'utilsateur.

Saluons l'initiative mais regrettons qu'il faille que ce soit à reculons qu'ils se lancent dans le libre.Si Google n'avait pas été là , je ne suis pas sûr qu'ils auraient eu la même démarche.

Ce n'est pas du tout le sujet de la discussion. La discussion ne porte pas sur la rigueur, la cohérence, du processus de décision. Elle porte sur ses critères.

D'autant que si on compare avec le processus de dev de Linux, Linus serait vraiment mal placé de faire des réflexions sur ce point.

langue de Blois

Je connaissais la langue d'Oc et la langue d'Oil, mais je ne savais pas que la ville de Blois avait participé si activement à notre culture nationale.

Je pense que c'est cette forme d'ostracisme à l'égard des blésiens (aurait dit Maître Capelo) qui te vaut cette descente en règle ;-)

Remarque ! Ca nous change des communistes ou des intégristes.
J'aurais préféré fasciste on aura gardé le même suffixe comme ca o:)

Je l'ai toujours dit , les devs de kopete c'est des vrais malades

se remettre à l'eau ferrugineuse

Marrant !
Quand on évoque le fait que tu peux faire des pepettes en vendant des logiciels en GPL mais que le modèle n'est pas viable et que GPL et payant c'est pratiquement antinomique, tu te fais systématiquement détruire.
Là tu lâches :

Bref le modèle économique du logiciel propriétaire est souvent de faire des sous sur les licences en organisant la rareté. Effectivement, on ne peut pas faire ça avec du logiciel libre pour les raisons que tu as développées au dessus.

En gros, on ne peut pas appliquer un modèle payant/proprio au libre en faisant payer un logiciel en GPL sauf à se rémunerer sur les services et tu te retrouves au firmament.

Va comprendre Charles !

Plutôt que de poster sur un forum , on lâche l'air de rien
"Un truc qui manque à Linux"
et on fait croire que c'est une feature qui manque comparé à Oindoze,
Linux à la ramasse toussa.

Un peu d'enrobage et Hop une foultitude de loupiauds qui font jamais un détour sur les forums qui se déchainent pour lui répondre.

C'est presque aussi subtil que sa façon de lancer les trolls politiques :)

Bonjour , je m'apelle "Bot l'Emmerdeur" et j'écume DLFP parce que j'aime bien voir les gens perdre patience.

A se demander ! Vraiment.

Tu peux développer un peu , car j'ai pas tout compris par liaison tu entends phase après compilation ou chargement de la lib sur le poste du client.

Si ce que tu dis est vrai il n'y a donc aucun problème pour les projets Open Source et le seul pb qui subsiste est pour les logiciels proprios.

Dans ce cas il est normal qu'il payent en retour les contributions sur lesquelles ils s'appuient pour faire du bizness.

Je te rappelle juste que tu fustigies (un peu) la licence BSD,

Tu dois confondre je n'ai fait que défende la stratégie de Trolltech et j'ai juste posé une question.

Sans Rancune ;-)

La différence est dans le fait que les bibliothèques LGPL ne sont en général pas fournies par une société qui doit faire vivre ses employés et repose uniquement sur le bon vouloir du bénévoles ou de sociétés qui espèrent se rémunérer sur le service, au risque de se faire tailler des croupières par une autre société qui recolte la mise sans rien produire en retour.

Quand tu développes un logiciel libre, en général, tu as conscience des implications du mot "libre" . Lorsque tu choisis donc la licence des composants que tu utilises tu dois donc faire preuve de la même compréhension à l'égard des fournisseurs de composants et de leurs motivations. Surtout si tu es une société éditrice.

Au fait ! Peut-on faire du GPL avec du BSD ? (je pense que oui mais j'attends une confirmation)

A combien de grammes ?

Peux tu mettre le CD en download m^me sans les sources:

Je remonte dans ma famille à Noel et j'aimerais bien faire un petit cadeau.

Et comment tu fait quand tu es éditeur et que tu veux pas qu'une boite s'approprie ton code pour le revendre.


Tu veux vendre un logiciel en proprio => tu payes,
Tu veux faire du libre mais tu n'as pas la possibilité de forker en proprio => GPL

CQFD

Licence comtaminante,
Double licence et éditeurs qui veulent vivre :

Eternel débat

En même temps pour que l'utilisateur puisse bénficer d'une offre logicielle qui les satisfasse il faut aussi industraliser le developpemnt logicile afin d'être en mesure de produire suffisament. La conception d'une architecture evolutive est doonc essentielle.
Si on en était resté à l'assembleur, je doute que les utlisateurs aient eu autant de choix qu'aujourd'hui.

Mais peut-être que la couche de logicielle imposée par X est de trop si on la compare aux autres OS (MacOs, Windows, BeOS, ...) .