Considères par exemple le cas des innovations introduites dans l'encodeur LAME, malgré les brevets concernant le MP3
ces innovations sont inutiles sur Thomson et Frenhaufer décide d'interdire a lame d'exploiter le brevet sur le mp3.
Encore une fois tu t'arretes uniquement sur la 'spécification' de l'espéranto. Il est évident que sur papier c'est génial, puisque comme tu nous l'expliques c'est une langue faite pour éliminer les ambigüités.
Mais, une fois qu'il y aura des gens qui le parleront pour d'autres raisons que pour le fun, alors il y aura des distorsions, comme il y en a dans toutes les langues vivantes.. Alors d'accord, ce ne sera pas de l'espéranto académique qui lui restera génial, mais il n'empèche que des gens parleront espéranto "petit negre" tout comme on parle anglais "petit nègre" à l'heure actuelle, peut-etre moins distordu que l'anglais, va savoir, mais distordu quand même et avec toutes les incompréhensions que ça peut générer.
Exemple concret : L'esperanto quoique tu en penses est une langue vivante parlée par de vrai gens qui converse de tout et n'importe quoi
En effet, tu as raison, ça m'apprendra à prendre wikipédia comme référence :)
D'après le dictionnaire de l'académie française (http://www.academie-francaise.fr/dictionnaire/(...) et http://atilf.atilf.fr/academie9.htm(...) ) : Langue morte, qui n'existe plus que dans les écrits, par opposition à Langue vivante, qu'un groupe humain parle actuellement.
Quelque part c'est une excellente illustration des distorsions (ici elle est sémantique) dont je parle. D'après l'académie française (ceux qui spécifient la langue française) : est vivante une langue quand des gens la parlent. Soit...
Mais bon, je constate que ce n'est pas l'usage courant, le mien, celui de mon entourage et chez les gens de wikipédia. D'ailleurs, je parie que ce n'est pas le tien non plus, et que comme moi et contrairement au spécifications de l'académie française, tu n'appelleras pas le latin ou le klingon "langues vivantes". Pourtant => http://www.kli.org/(...) .
Il y a donc une source d'ambiguité, puisque ce mot n'a pas le meme sens pour les gens comme moi que pour les gens qui parlent le français académique. Marrant, ça ne vient carrément pas de la structure de la langue, ni de sa spécification qui elle me semble on ne peut plus claire...
Serait-ce parce que le français est une langue vivante ?
Je ne vois pas le probleme et je serais même assez d'accord avec ton "paralelle", si tu l'avais fait correctement :
---- Je ne vois pas en quoi ça remet en cause ce que je dis. Que Linux soit un OS facile à apprendre etc, sans doute... Pour ma part je le connais pas et je ne m'y interesse pas.
Ce que je dis c'est qu'actuellement, windows est déjà enseigné partout, qu'il est utilisé presque partout sufisemment pour qu'on se comprenne. Les windowsiens sont avantagés ? Tant mieux pour eux ! Je préfère voir un OS avantagée parmis d'autres que toute désavantagées. D'ailleurs, tu le dis toi même : Les personnes capables d'utiliser aussi bien un autre OS que l'OS sur le quels ils ont appris sont très rares. Quelle différence avec Linux/Windows/ce_que_tu_veux ?
Jusque là tout va bien
Mais bon, pour ma part, je n'utilise plus beaucoup windows, mais ce n'est pas pour ça que je tiens a imposer linux au monde sous pretexte que je le trouve plus adéquat et mieux foutu.
Si les unix-like ou le libre finissent par tourner partout, j'espere que ce sera parce qu'ils s'imposeront d'eux même, pas juste parce qu'on en a imposé l'usage. Idem s'ils doivent en venir a disparaitre : j'espere que ce sera parce qu'on en veut plus et non parce qu'on a tout fait pour les tuer.
Linux est un OS vivant, utilisé par plus de deux millions de personnes à travers le monde.
Là, c'est n'importe quoi. Je te parle d'une définition : une langue vivante est une langue qui est la langue NATALE de personnes encore en vie, cf http://fr.wikipedia.org/wiki/Langue_vivante(...) . Le concept d'OS vivant reste encore à définir. Ce qui rend cette partie du parallele totalement dénuée de sens.
Mais si ton paralelle me semble imparfait, c'est surtout parce que l'on parle d'une langue et non d'un OS, c'est sensiblement différent.
Un OS est un environnement informatique qui fournit des moyens à ses utilisateurs. On pourrait distordre le concet au point d'imaginer qu'un OS est un moyen de communication, mais même dans ce cas, il ne permet de communiquer que des concepts discrets, et il est prévu pour un contexte particulier : donner des information et recevoir des ordres, rien de plus.
Une langue est 'protocole' d'échange particulièrement évolué qui lui permet de faire passer une infinité de nuances et de concepts que n'atteindront pas de si tot nos dispositifs informatiques parce que c'est fait pour la communication entre êtres humains et sous toutes ses formes, pas uniquement pour une simple interaction ordre / information.
Maintenant, on peu considérer qu'un OS fournit un environnement et une culture qui ont peut-être une certaine ressemblance avec une langue parlée par des gens, mais ça n'a certainement pas la même importance à mes yeux dans la vie de tous les jours, et ça touche directement énormément moins de monde.
Ce que je peux tolérer avec un OS, je peux tres bien ne pas le tolérer avec quelque chose d'aussi omniprésent que le langage courant.
Justement le fait que l'esperanto soit très facile à apprendre permet d'atteindre rapidement une très bonne maitrise de la langue.
Une bonne maîtrise, mais pas une manipulation comme si c'était ta langue natale.
La prononciation de l'esperanto a été fixé une fois pour toute.
Ce n'est pas pour ça que les gens vont la suivre. Pour exemple, la prononciation et le vocabulaire, en francais, ont aussi été aussi fixés, même si c'est plus complexe qu'en espéranto, semble-t-il. Ca n'oblige pas les gens à la suivre et avec le temps, pour ne pas être completement à côté de la réalité, l'académie française réajuste le tir en incluant les nouveaux mots et nouvelles prononciations.
Pour les exceptions je ne vois pas du tout en quoi cela serait un avantage
Ce n'est pas un avantage, c'est une caractéristique d'une langue vivante. Les gens rajoutent des mots, des tournures dans langue, et ces tournures introduisent parfoit des exceptions.
Donc, soit l'organisme ignore ces exceptions et crée des dialectes (la langue officielle est distinguée de la langue réellement parlée, celà fait au moins un dialecte), soit il inclue les exceptions pour rester proche de la réalité de la langue.
Justement si le contexte n'est pas clair, ou que l'on ne maitrise pas le sujet il est parfois difficile de comprendre.
Je suis sur que tu peux trouver ce type d'ambigüité quelle que soit la langue, y compris l'espéranto. Ne serait-ce que parce que l'auteur fait une figure de style.
Ah bon, par des personnes qui l'utilisent dans des discussions/courrier? Là tu m'étonnes!
Il y a 50 ans, oui, car c'était encore un signe d'érudition, il n'y a qu'a voir le nombre de gens qui ont appris le latin dans les 50 dernières années en France.
Ne serait-ce que les ecclésiastiques, qui le parlaient régulièrement dans les messes en latin.
Il est clair que maintenant, les gens capables de parler courrement le latin, ça doit pas courir les rues, pas plus que l'espéranto d'ailleurs.
Je trouve même que dire que l'Esperanto n'est pas une langue vivante est plutôt injurieux
Ce n'est pas mon but. Mais, que tu le veuilles ou non, il n'empeche que ce n'est pas une langue vivante, par définition. Remarque ce n'est pas une langue morte non plus car ça n'a jamais été une langue vivante.
De plus il existe des personnes (certes peu nombreuses) pour qui c'est la langue natale.
Je parie que je peux les compter sur une seule main :) De plus, je doute, vu la faible concentration des espérantophones (?), que ces personnes utilisent l'espéranto pour leur échanges humains quotidiens.
Je ne vois pas en quoi ça remet en cause ce que je dis. Que l'Espéranto soit une langue facile à apprendre etc, sans doute... Pour ma part je ne la connais pas et je ne m'y interesse pas.
Ce que je dis c'est qu'actuellement, l'anglais est déjà enseigné partout, qu'il est parlé presque partout sufisemment pour qu'on se comprenne. Les anglais sont avantagés ? Tant mieux pour eux ! Je préfère voir une langue avantagée parmis d'autres que toutes désavantagées. D'ailleurs, tu le dis toi même : Les personnes capables de parler aussi bien l'anglais que leur langue maternelle sont très rares. Quelle différence avec l'espéranto ?
la prononciation varie selon le pays
Justement parce que c'est une langue parlée partout. L'anglais comporte des règles précises (il suffit de prendre un dictionnaire d'anglais et tu as la prononciation en Queen's English, l'anglais académique) mais elles sont distordues selon les pays parce que les gens parlent la langue à leur sauce. L'espéranto aura très probablement le même problème si son succès augmente.
Je ne vois pas ce qui ferait que l'espéranto échapperait à cette tendance naturelle.
La déclinaison en dialectes d'une langue n'est clairement pas liée à sa structure mais à son usage (exemple : l'argot).
Même chose pour : La grammaire est très simple, aucune exception.
Quelqu'un dans le thread à proposé d'enlever l'accent circonflexe de forêt, parce que c'était une source inutile d'erreur. N'est-ce pas une excellente illustration de modification des règles d'écriture dûe au caractère vivant de la langue ? Avant on disait "forrest" (cours ! cours !) , on écrivait un s, on s'est mis à dire "foré", on a remplacé le s par un accent, et maintenant, on considère qu'il n'est pas besoin de rattacher le mot à sa racine (on fait quoi pour forestier ?), on propose de virer l'accent.
Si l'espéranto était une langue vivante elle verrait fleurir néologismes et autres distortions du même type qui introduiraient assurément et rapidement les exceptions qui manquent à l'espéranto, tant au niveau grammaire qu'au niveau vocabulaire.
l'anglais est une langue parfois très vague
Soit c'est voulu, soit c'est mal exprimé. Si tu veux bien te faire comprendre, tu peux, même si tu n'as pas le vocabulaire nécessaire : le contexte est là pour ça. Je ne parle pas l'anglais couremment mais je n'ai que très rarement eu de problèmes d'ambiguité, comme quoi ce n'est pas si difficile à maîtriser en tant que langue internationale. Quelque soit la langue, tu auras toujours des ambiguités si la personne en face le désire ou s'exprime mal.
L'espéranto est une langue vivante, parlé par plus de deux millions de personnes à travers le monde.
Alors là je dis non ! Le latin est parlé par plein de monde, ce n'est pas ça qui en fait une langue vivante. Une langue vivante c'est une langue natale, utilisée courremment au quotidien par des gens qui l'ont apprise dès leur plus jeune age, ce qui fait qu'elle évolue au fil du temps ( http://fr.wikipedia.org/wiki/Langue_vivante(...) ). Ce n'est pas le cas de l'éspéranto.
D'ailleurs, si c'était le cas, l'espéranto se déclinerait rapidement en dialectes et deviendrait une langue comme les autres, difficile à maîriser, surtout quand ce n'est pas la langue natale.
Cette domination est sournoise car elle conduit à une uniformité de la culture,
Pas dans l'utilisation d'une langue commune : les gens parlent la langue commune pour des rapports internationaux (enfin, plutot interlinguistiques :)), et continuent à parler dans leur langue natale le reste du temps. Je ne checke pas les news et pourtant je parle plus ou moins anglais.
on pourrait facilement désambiguer "free"
Ce serait pour créer d'autre ambiguités...
Je ne comprend que le français, l'anglais et un peu d'allemand et de japonais mais je sais qu'une suite de deux mots peut façilement être ambigüe au même titre que free software, quelque soit la langue.
Exemple en français : bière fraiche => je parle du cerceuil ou de la boisson ? La seule chose qui te permet de la savoir c'est le contexte : tu sais que socialement, en France, parler de bière fraiche au sujet d'un décès c'est quelque chose d'incongru et de culturellement répréhensible. Pour ces raisons, je pense qu'une langue sans culture ne peut permettre de s'exprimer aussi finement qu'une langue basée sur une culture.
Un mot amène un poid, une direction à la discussion, que tu modères ou accentues en fonction de ta culture, de ce que tu comprend de la culture associée à la langue, et du contexte discuté. Une langue nouvelle ne changera pas ça et pire encore, elle ne le permettra pas.
Et puis, en admettant qu'il existe une langue où chaque concept aurait une racine propre et distincte, afin d'éviter les ambiguités, où le contexte ne tiendrait pas un rôle majeur, cette langue aurait un vocabulaire tellement riche qu'elle ne serait pas humainement utilisable car il faudrait des années pour maitriser son vocabulaire. Ou alors, il lui manquerait tellement de concepts qu'elle serait très limitée dans son usage.
Pour le coté inaudible, j'avais lu un article (je ne sais plus où) sur une étude où l'on tentait d'expliquer pourquoi les francais sont des cancres en langues.
Et l'aspect culturel, il est pris en compte ? Ne serait-ce pas lié aussi au fait que les Français ont jusqu'a peu été une puissance dominante et qu'ils sont un peu réticents a admettre qu'ils ne sont plus qu'une puissance moyenne ? Le français a été la langue diplomatique pendant des années, et maintenant ne serait-ce pas réaliste de considérer qu'on a un peu de mal a s'adapter à la nouvelle donne ?
Les Japonais ont le même problème de langue que nous (il n'y a qu'a entendre un japonais parler anglais ou allemand...), et comme par hasard, ils ont été aussi nombrilistes que les français jusqu'a la fin du 19eme sciecle...
Sans parler des méthodes d'apprentissage... Ce qui m'a fait comprendre l'anglais, c'est de lire de l'anglais, ce n'est clairement pas les cours au lycée où en fac.
A mon avis, le coup du spectre ça doit jouer, mais ce n'est certainement pas la seule raison.
Ceux qui se plaisent à parler petit nègre en anglais peuvent peut-être se satisfaire de la situation actuelle, mais pour ceux qui aspirent à un autre niveau de communication, ceux-là ont le droit de s'intéresser à l'espéranto.
L'anglais ou l'espagnol sont les deux langues européennes les plus répandues dans le monde. En Europe, je parie qu'il y a plus de gens qui parlent ou bargouinent l'anglais que l'espagnol, et je comprend tout à fait que nos députés européens aient préfèré et imposé l'anglais.
Un des nombreux avantages de l'anglais sur l'espéranto, c'est que tu peux t'immerger dans un milieu anglophone pour arrêter de parler un anglais bizarre : c'est une langue vivante.
Bref, utiliser l'espéranto reviendrait à limiter encore plus l'accès aux documents de ce type puisqu'une minuscule minorité de gens seulement le parle. Et je ne vois pas l'intéret d'investir de l'énergie pour faire apprendre une langue qui n'a jamais servi et qui ne sert pas actuellement, surtout pour remplacer une langue réelle qui a fait, et fait encore très bien l'affaire.
Maintenant, si on devait choisir une langue détachée de toute nationalité, je voterais pour le Noir Parler de Morgul, vu l'europe qu'on se prépare et vu les méthodes utilisées pour la mettre en place...
Je pense que la modélisation physique n'a pas grand rapport avec le moteur de rendu 3D.
Entierement d'accord mais tant qu'a y être, autant prendre le moteur de rendu livré avec le moteur physique, surtout quand il a bonne réputation et qu'il n'y a pas besoin de le déployer (en théorie) puisque intégré à l'OS.
Si directX est plus connu c'est qu'il date de 1995 alors que SDL date de 1998. Il a aussi profité d'une réclame efficace.
Mouais, enfin, c'est surtout qu'il est fait par et pour MS, que c'est de bonne qualité, qu'il est installé de base (avec support de mise à jour par win-update) avec la plate forme dominante pour le jeu sous PC.
Par ailleurs à l'époque les cartes qui implémentaient efficacement openGL étaient très cheres alors que directX permettait de faire de la 3D logiciellement de manière efficace.
Quand DirectX a vraiment percé (version 3.0), les cartes grand public supportaient les accellérations matérielles : 3dfx, g200... Ce n'était pas donné pour le pékin moyen, mais c'etait complètement dans les prix du hard core gamer (et même moins cher que les cartes haut de gamme actuelles : 1200FF une 3dfx à sa sortie contre 300 euros la GeForce 6800, par exemple)
Pour une _entreprise commerciale_, c'est le juste milieu qui est important. Manifestement il a échappé à pas mal de décideurs.
Le modèle de vente de licences d'utilisation de logiciels est un modèle foireux justement parce que ça dérive sur ce que l'on peut constater de nos jours : plus d'argent injecté dans le droit et la pub que dans la recherche et développement.
Je pense que plus ça va aller dans ce sens, plus une la survie d'une petite société éditrice deviendra difficile puisqu'elle n'a pas les ressources nécessaires pour investir dans le droit. Et comme elle "vole" forcément la "propriété" des autres sociétés (le clic, la fenetre, le nom, etc) et dès qu'elle grossit un peu trop, elle est devient la cible de procédures judiciaires ce qu'elle ne peut pas se permettre....
Le juste milieu du marché du soft c'est la vente de services, et ça, ça prend du temps a être compris, mais ça viendra bien un jour : il n'y a pas d'autre choix :)
Les gens qui font du proprio piquent aussi, volontairement (sigma) ou non (MS), du source chez les autres, et sont tout aussi exposés au procés et autres complications juridiques.
Bref, tu es emmerdé pareil sinon pire, vu que tu risques nettement moins si tu pompes du source libre pour produire du libre : la puissance du copyleft en action :)
Néanmoins je ne connait aucun logiciel professionnel utilisant DirectX. Et Pixar et compagnie utilisent Linux et OpenGL
Ton argumentaire me fait penser à : 10 milliards de mouches ne peuvent toutes se tromper : mangeons de la merde !
Si on n'utilise pas beaucoup DirectX dans les applications pro (genre ce que pixar peut utiliser, par exemple), au hasard, serait-ce à cause du fait qu'OpenGL serait plus adapté aux application de modélisation / rendu hyper réalistes et DirectX orienté vers l'animation et modélisation du monde (pas seulement moteur graphique mais aussi physique) ?
Beh il me semble que le but d'un programme est de répondre à des besoins précis. Si parmis ces besoins ne figure pas le partage et la réutilisation, il est n'est pas nécessaire des les y faire figurer, ça complique plus ou moins le développement et ça amène parfois à l'échec du projet : trop compliqué (à développer / déployer / utiliser / maintenir) pour son but premier.
Tu as expliqué ce que tu pensais en disant : "interfacer une ligne de commande c'est faire n'importe quoi". Ca me gène dans le sens ou parfois c'est une très bonne solution. Maintenant, je suis d'accord avec toi sur le fait que faire ça systématiquement est une mauvaise approche.
Il est évident que d'utiliser ce principe pour de l'intéractif, ce n'est pas très malin. Je n'arrete pas de le dire... Dans ce même ordre d'idée, en ce moment, ce qui me chagrine c'est qu'on essaye de remplacer les applis C/S par des applis web. Pourtant, le web est encore moins interactif que la ligne de commande puisque le serveur ne peut rien envoyer spontanément au client : impossible de notifier sans faire crado un changement dans les données aux clients, par exemple : inadapté pour certaines situations.
Pour ce qui est des programmes irremplaçables, il est clair que ce serait peut-etre mieux de les avoir sous une autre forme, parce qu'ils permettraient sans doute de mieux répondre aux évolutions des besoins. Maintenant qu'on a le programme, on lui en demande plus.
Mais, l'informatisation est un processus itératif et les besoins évoluent sur la base existante. Avant, il n'y avait rien, les besoins c'était d'aboir un outil qui fasse le boulot. Maintenant qu'il y a un outil qui fait le boulot, on lui demande de le faire différement ou de faire des choses en plus. Les premiers développeurs n'ont pas fait n'importe quoi : ils ont répondu aux exigences qu'on leur a fixé. Il me semble compréhensible qu'ils n'aient pas eut en tête les besoins modernes, surtout quand le projet remonte à une époque ou l'interface graphique était atypique (cette fameuse époque où la ligne de commande était reine).
Mais, on peut se poser la question suivante : pourquoi ne remplace-t-on pas ces programmes ? L'effort de développement ne serait-il pas trop cher payé pour le gain ?
J'ai pris pour exemple le cas de cdrecord/gcombust parce qu'il me semble assez représentatif : pas top niveau ergonomie mais ça grave bien et suffisement simplement. Le rapport effort de développement / gains n'est peut-être pas encore assez interessant pour que quelqu'un en fasse une lib de gravure.
dans le cas de ton lecteur mp3, comment tu indiques (...) merci pour l'info.
Tu n'as pas l'impression que tu rales parce qu'un logiciel ne répond pas a ton besoin ? Tout ce passage c'est : comment je fais ci ou ça avec ? La réponse est : tu ne le fais pas vu que ce n'est pas fait pour ça.
Tu aurais une lib de gravure avec juste gboolean burn(char* isoname) ça serait le même problème. Ta critique porte sur les fonctionnalités de cdrecord, non pas sur les techniques utilisées par son interface pour communiquer avec.
(..)C'est juste une question de bonne pratique(...)
Oui, dans le but de maintenir le machin et d'en faire quelque chose d'évolutif. Parfois, on fait un truc tout con qui répond juste a un besoin et alors, la bonne pratique est de faire simple. Ensuite, la séparation peut tres bien etre faite, au moins au niveau source. C'est juste que tu n'as pas envie de te taper les contrôles inhérents à la création d'une lib parec que tu ne programme que pour une ligne de commande.
ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général (...)à parser par une application tierce-partie
Il ne t'est jamais venu a l'idée que ce n'etait pas fait pour ? Encore une fois, tu rales parce que tu essayes d'utiliser un outil dans un contexte pour lequel il n'a pas été fait (typiquement, le fait de parser des fichiers config automatiquement alors qu'ils ne sont pas faits pour ça).
Les config XML c'est l'inverse. Avec VI, le XML c'est infect et illisible. Normal ce n'est pas fait pour ça.
Dans un cas c'est documenté, pas dans l'autre.
Si le gars ne documente pas, commande ou lib, tu es dans les deux cas dans la mouise. C'est un probleme de doc, pas de techno.
C'est pas un peu très idiot ?
Pas plus que de transformer un appel interne du front end en un appel à une lib. LA lib traitera aussi les parametres pour s'assurer qu'ils sont valables et accesoirement, les transformera peut-être pour ses besoins internes.
Le principe est le même : c'est une transformation des parametres transmis au frontend pour l'envoyer vers le truc qui va éventuellement les transformer afin d'éxecuter sa tache avec les bons paramètres.
Il n'y a que le chemin technique qui differe. Dans certains cas, c'est plus facile par du code, dans d'autres c'est plus facile via une ligne de commande.
Juste pour la précision (...) je ne vois pas en quoi celà va dans ton sens
Je n'ai cité ça que pour illustrer le fait que, comme mes autres exemples, quand les methodes lègeres sont sorties du panier, elles etaient souvent présentées comme LA solution à tous les problèmes. Comme toujours, on en est revenu et on les considère maintenant que comme un des outils pour gérer un projet, au même titre que les autres méthodes. On choisi de les utiliser ou pas en fonction du contexte du projet, pas uniquement parce que çai mieux (tm).
La ligne de commande comme IPC, n'est pas plus que la librairie, l'interface ultime, même si d'après toi elle a été présentée comme tel. En tous cas, je n'ai jamais affirmé que c'était LA solution, je dis juste qu'il est crétin de la bannir sous prétexte que çai mal (tm).
Oui effectivement, seulement si il a les sources.
Oui evidemment :) De toutes façons, si tu n'as pas les sources, lib ou commande, tu feras très probablement des trucs porky si tu veux étendre les fonctionnalités de l'outil, parce que tu ne pourras faire les ajustements nécessaires dans l'outil pour qu'il prenne en charge tes nouvelles utilisations.
Celà peut être légitime(...)communication privilégié
1- je ne vois pas en quoi les chaines de caractères sont des formats à la con : c'est humainement compréhensible (contrairement à un hash, ou une structure/record ou autre type composite) et ça se génère et gère tres bien dans bon nombre de langage (je ne connais que le C qui rend leur gestion plus délicate).
2- un programme est fait pour être utilisé dans un but et dans un contexte. Il est évident que si ton programme n'est fait QUE pour des machines, il existe d'autres moyens que la ligne de commande et probablement plus adaptés. Maintenant, si tu veux quelque chose d'utilisable par des humains (une commande) et parfois, par des machines, la ligne de commande c'est une possibilité qui peut s'avérer plus interessante que les autres, particulierement dans le cas que j'ai cité : paramétrage d'un processus long et non interactif.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant.
Non, ça joue le morceau que je demande, ça l'arrete quand je n'en veut plus ou quand il est terminé, le tout en mode graphique : ça fait ce pour quoi c'est fait.
il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité.
Dans ce cas, on devrait utiliser une librairie :) Ce n'est pas très malin de passer par la ligne de commande si on veut de l'interactivité durant le traitement. Il me semble que je l'ai déjà dit avant.
Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure...
Non, mon besoin c'est : je selectionne tous les paramêtres de la gravure graphiquement, je clique sur GO et quand c'est fini le frontend me dit "ça marche / ça marche pas" en fonction du résultat : la ligne de commande c'est nickel pour ça.
Si tu as les besoins que tu cites, alors oui, utilises une lib.
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire
Beh si. Il te faut coder ta lib béton parce que l'utilisateur de la lib peut t'envoyer du yahourt. Si je fais un burn(NULL), et que tu ne testes pas dans burn() tes paramètres d'entrée, alors segfault. Si j'ai une fonction burn() identique dans un programme et pas en lib, je n'ai pas besoin de faire ce test, parce que je sais que je n'y enverrais jamais NULL si je sais que j'ai fait le controle en amont.
Evidemment, ce n'est qu'un exemple, mais ce n'est evidemment pas le seul et puisque tu demande un truc indépendant du langage (d'ailleurs, le débordement de buffer ce n'est pas spécifique au C), en voila un autre :
Toujours en restant sur l'exemple de la gravure, tu dois vérifier dans burn() que le device cible existe bien, ou au moins gérer l'erreur si l'utilisateur de la lib envoie n'importe quoi. Si c'est une fonction intégrée un programme complet, ce n'est pas forcément nécessaire si tu as fait le controle en amont (si l'utilisateur n'a qu'un choix limité, par exemple).
De toutes manières c'est hors sujet.
D'ailleurs, il me semble bon de rappeller, au milieu de ce troll, que le sujet n'est pas "la librairie c'est mieux". Le sujet est "c'est abérrant d'utiliser des redirections d'I/O dans des programmes". Mon propos est : "parfois les redirections d'I/O c'est plus adapté qu'une API" et le tien, si je l'ai bien compris est : "dans tous les cas, il devrait y avoir une API et on ne devrait jamais utiliser la redirection I/O comme ipc".
plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Ce ne sont pas que des habitudes : les mecs qui utilisaient ça plutot qu'autre chose le faisaient de manière aussi réfléchie que maintenant. Certaines de ces réflexions ne sont peut-etre plus valables aujourd'hui, d'autres le sont encore.
Et puis, dépassé, ça veut dire quoi ? Qu'on a forcément mieux dans tous les cas avec une techno plus moderne ? J'aimerais bien y croire. Ce que tu gagnes quelque part sur une techno réfléchie (même vieille), tu le perds généralement ailleurs. La polyvalence et la simplicité d'une redirection d'I/O contre la puissance et l'exclusivité d'une API....
Et également pour la récupération du résultat aussi
Tout a fait, mais dans certains cas (les cas que j'ai cité en exemple), le résultat c'est "ça marche" / "ça ne marche pas". C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Sans parler de l'absence de tous les protocoles spécifiques à la communication entre programmes : types de données, exceptions, synchronisation, etc.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :) De plus, il y a plein de domaines ou il n'y a pas de protocole consensuel ou standard. Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Sans parler qu'il a création inutile de processus quand un simple thread suffirait voir rien du tout.
Si les ressources systeme ne sont pas des ressources critiques, je ne vois pas le mal qu'il y a à créer un processus supplémentaire.
Non effectivement on a inventé celà y'a 20 ans, en croyant qu'on allait pouvoir tout faire avec ça
En 20 ans, on a lancé d'autres modes diverses et variées en croyant qu'on pouvait tout faire avec :
- tout stocker avec une approche relationnelle (même les fichiers !)
- tout stocker en XML (même les fichiers config !)
- tout faire avec une approche modulaire
- tout faire avec une approche l'objet (aaaah les BD objets :) )
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
- faire toutes les interfaces graphiques
- rendre tabou le goto
- passer toutes les applications C/S sur des technos Web
- tout faire passer par le port 80
- tout sortir du noyau
- etc., etc....
L'erreur n'est pas dans la techno mais dans le fait qu'on pense tout résoudre (et en mieux en plus) avec une seule approche. Si à chaque fois qu'on trouvait la méthode / techno universelle de la mort qui tue, ses évangélistes donnaient 10¤ à l'ONU, on pourrait s'acheter la paix dans le monde :)
Une approche unique ne convient pas à toutes les problématiques. S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée. Et moi, je n'aime pas me compliquer la vie quand ce n'est pas nécessaire.
de nombreux programmes ont été conçus sans du tout penser à proposer une interface de programmation plus avancée EN PLUS
Je vois pas pourquoi j'irais faire une interface de programmation plus avancée EN PLUS si celle que j'ai répond à mon besoin. Si quelqu'un utilise mon programme, soit il a les mêmes besoins que moi (et l'interface existante devrait lui convenir), soit il a des besoins proches mais pas identiques et ce n'est pas à moi de résoudre ses problèmes : il prend mon programme et en fait une lib s'il a besoin d'une lib.
bref c'est valable pour la plupart des GUIs
Je n'ai jamais dit le contraire. Mais bon, la plupart ce n'est pas toutes. J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
mais je cherche toujours les avantages de n'avoir QUE une interface console
Ca me semble évident : du moment que ça répond au besoin, tu t'embetes pas a faire une lib et/ou un composant : tu peux ne gérer que tes cas à toi, ce qui n'est pas le cas d'une lib ou d'un composant.
Par exemple, tu ne vas pas gérer un débordement de buffer dans ta lib parce que ce sera controlé en amont, au parsing de la ligne de commande par exemple. Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle : au parsing des arguments ET à l'entrée de la fonction qui traite un des arguments, sinon tu risques le segfault dans l'une ou l'autre partie de la chaîne.
En tout cas tu confirmes ce que je disais : pour linux aussi les habitudes des utilisateurs sont un vrai boulet à traîner.
Je pense que tu n'aimes pas les mêmes gens que moi : les gens qui fustigent une techno et qui sont des boulets à cause de leur inaptitude a s'adapter au but parce qu'il sont limités à une seule approche.
Bof, je continue à penser que c'est une IPC comme les autres qui a ses avantages et inconvéniants. Pour reprendre ton expression, on a pas inventé la redirection des I/O standard pour les chiens non plus. Dans pas mal de cas, c'est nettement plus pratique qu'une lib ou un composant.
Et puis, la perte de perf n'est vraie que pour la génération des parametres et le passage de ces paramètres. C'est un parametre parfois critique et il vaut mieux éviter la commande si tu lances beaucoup de fois le processus et que ce processus est rapidement traité : dans ce cas, la lib va bien mieux, c'est clair.
L'autre limitation de l'utilisation d'une commande c'est que ce n'est pas le pied pour un processus interactif, dans ce cas, c'est sur qu'il vaut mieux éviter.
Mais sinon, si tu lances un processus long qui n'est pas interactif, interfacer une commande va tres bien (cdrecord / gcombust ou mpg123 / frontend quelconque, par exemple), et je ne vois pas ce qu'amènerai de plus l'utilisation d'une lib.
choses aberrante comme des dizaines de front-end qui gère un programme console en lisant et en écrivant sur ses entrées et sorties standards.
Je ne vois pas ce qu'il y a d'absolument aberrant la dedans ...
Sur le principe c'est plus ou moins la meme chose qu'un machin tout intégré a la sauce composant ActiveX ou KPart, ou que l'utilisation d'une dll. C'est le principe du découpage des taches et de la ressource partagée: la commande ou le composant execute une tache plus ou moins bien découpée et on le commande par une interface plus ou moins bien définie. De plus, plusieurs programmes peuvent utiliser cette ressource sans avoir besoin d'en réinstaller une équivalente.
Ca a même l'avantage de pouvoir tourner sans interface additionnelle (puisque c'est déjà intégré dans la commande shell), alors que ton composant, tu aura forcément besoin d'une interface additionnelle pour en tirer quelque chose. Sans compter que généralement, les dépendances des composants sont très nettements suppérieures à celle d'une commande shell.
Inversement, c'est pas gagné pour faire du glisser graphique avec une commande shell :)
M'enfin d'un point de vue technique, utiliser une lib player mp3 et l'intégrer dans un programme graphique, utiliser un composant player mp3 et l'intégrer dans une interface graphique ou piloter un mpg123 like par une interface graphique, c'est un choix qui se fait en fonction de ce qu'on veut faire et qui n'est aberrant qu'en fonction de ce qu'on a voulu faire.
D'un point de vue utilisateur, du moment que ça répond au besoin, on se contrefout de comment c'est fait...
Et je ne parle du fait que le moindre accès disque soutenu sous linux équivaut à la quasi-inutilisabilité de la machine
Active le DMA sur tes disques sous linux.
mais d'expérience, un Windows 98SE sur un vieux pentium avec peu de ram s'en sort encore beaucoup mieux qu'un linux aussi tunné que possible avec le wm super léger de la mort...
Beh mon expérience c'est totalement le contraire :
Au boulot, j'ai un celeron 700 bousesque (un HP vectra) avec 192Mo de RAM. Sous Win98SE : reboot plusieurs fois par jour pour cause de manque de RAM (je ne sais pas pour XP ou 2000, mais 98 ne supporte pas d'être juste en RAM). Ouvrir un truc comme Eclipse sous windows avec word ouvert c'est le reboot assuré dans l'heure qui suit. Ce n'est pas le cas d'eclipse et de OO sous nux.
Du coup, j'ai installé une slackware 9.0 à sa sortie et depuis je ne bosse qu'avec ça (messagerie, gestion du serveur applicatif que je dois maintenir (code/config), production de doc / rapports sous OO).
Depuis ce temps là, je ne reboote plus ma machine en journée pour cause de plantages, et niveau rapidité, c'est pareil que pour windows en terme de démarrage d'application (sauf OO sous nux qui est plus lent que Word 2000 si ce sont les seules applis lancées).
La différence se ressent surtout dès que tu commence a avoir plusieurs applis lancées en même temps (ce qui est toujours mon cas), particulierement au changement d'application (le ALT+TAB quoi) : sous linux, le passage de moz mail a OO, c'est quasi immédiat. Sous windows, pour passer de moz mail à Word, c'est tres nettement supérieur à 30 secondes. L'ouverture d'applications sur un nux chargé reste correcte (OO et moz ouverts, Vim démarre en 2/3 secondes maxi) alors que sous windows ça se dégrade très très vite (moz et word 2000 ouverts, le notepad démarre en plus de 10 secondes).
Bref chez moi : - un explorateur de fichier (...) : Midnigth Commander, aussi ergo que explorer meme s'il peut paraitre moins beau, nettement plus rapide et surtout 200 fois plus stable ! - une suite bureautique qui tourne (...) : OO 1.1. Sous windows ou sous nux, elle ouvre plusieurs documents sans planter, ce n'est pas le cas de MS-Office sur mon poste. Sous nux, elle marche moins bien (quelques bugs d'affichages, entre autres) mais au niveau reactivité dans un environnement chargé, c'est sans commune mesure avec Word. - un navigateur qui ne met pas 3 plombes à s'allumer : vu que j'ai tout le temps le client de messagerie de moz ouvert, avoir un navigateur me prend moins de 3 secondes a vide, et moins de 10 secondes si j'ai OO d'ouvert. Sous Window, moz est plus rapide et moins instable qu'IE en environnement chargé (avec le client mail moz ouvert).
Pour résumer, entre les deux OS et sur une machine qui a 3/4 ans, bosser sous win est une plaie pour des problèmes de perfs et de stabilité, alors que sur un nux pourtant plus récent (et donc sensé être plus gourmand) la réactivité est correcte et la stabilité sans reproche. Cela vient peut-etre de l'antivirus, je n'en sais rien, mais c'est un fait.
Note que j'ai volontairement ignoré les problemes de virus et autres spywares que je n'ai plus depuis que je bosse sous nux, alors que mes collegues ....
Il peut être nécessaire de laisser l'utilisateur admin de sa machine justement pour installer des softs (les informaticiens par exemple), vu que tu n'as pas les ressources pour assurer cette gestion. Perso, ça ne me dérangerais pas qu'on m'enleve les droits admin (j'aimerais bien en fait) de ma machine mais bon, je plains les gars de l'infogérance qui vont devoir intervenir dessus toutes les deux minutes :)
D'un autre côté, ce n'est pas facile d'imposer à un key people le fait qu'il ne doit pas installer ses cochonneries sur le portable qu'il s'est fait acheter par la boite.
C'est peut-être débile d'un point de vue sécu mais bon, la sécu ce n'est pas non plus une fin en soi et si elle gène trop l'utilisation, il me semble logique qu'on la mette de côté : tout le monde ne fait pas dans le top secret, t tant que les virus ne font que gèner, on peut s'en accommoder.
Beh tout bêtement que ce n'est pas une taxe SACEM mais une redevance Tasca :)
La copie privée te permet de copier tout et n'importe quoi pour ton usage privé, hors logiciels et bases de données qui ont été exclus en 86, si je ne me trompe pas (attention toutefois à ne pas violer l'EUCD français qui, il me semble, a été intégré dans la LCEN).
Les auteurs de ce tout et n'importe quoi ont donc un manque à gagner et pour compenser, l'etat prelève une redevance sur les supports numériques qui sont très probablement déstinés a recevoir cette copie : CD / DVD vierges et disques dur d'appareil de reproduction multimédia (magnétoscopes numériques, probablement aussi les RAM des baladeur MP3.
Normalement, cette redevance est ensuite distribuée aux sociétés de gestions des droits de leurs adhérents : SACEM mais aussi surement l'équivalent pour les films.
Je crois que c'est distribué en fonction des ventes de chacun, mais je n'en suis pas sur.
Je ne suis pas juriste, mais à force de lire et relire les textes qui parlent de ça, je crois que je ne dois pas être trop à coté de la plaque. Si un pro de la loi peu confirmer ou infirmer, qu'il ne se gène pas :)
Les seuls autres qui semblent s'y opposer sont Bayrou (et il n'a pas de pouvoir pour le montrer par des actes) (et les députés européens UDF sont pour) et Madelin (il me semble).
Bah y a Rocard, il me semble, et il n'est pas Vert non plus.
Attention, d'apres ton lien, c'est IE qui tente un truc et si c'est supporté par le serveur (IIS au hasard), alors ok, on sort de la marche standard. Ca n'empèche pas que IIS supporte aussi le standard (embrace & extends qu'ils disaient :) ).
Oula, tu as raison, il semble que le type InnoDB comble nombre de lacunes qu'avait mySQL il y a 2 ans et que mySQL soit maintenant un moteur SGBD vraiment proche du standard SQL. Il reste bien des trucs a implémenter mais ils semblent vraiment vouloir les implémenter (ce qui, si je me souvient bien, n'etait pas vraiment la philosophie au début de mySQL). Au temps pour moi !
Mais ça n'enleve pas les soucis de compatibilités avec les standards dans le libre, même s'ils ne sont que des questions de temps... Tiens dans la série des exemples, j'aurais pus aussiciter les linux threads, qui se sont aussi beaucoup améliorés mais qui divergent toujours du standard sur la gestion des signaux...
[^] # Re: Il faudra de toutes façons faire qque chose
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 2.
ces innovations sont inutiles sur Thomson et Frenhaufer décide d'interdire a lame d'exploiter le brevet sur le mp3.
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 1.
Mais, une fois qu'il y aura des gens qui le parleront pour d'autres raisons que pour le fun, alors il y aura des distorsions, comme il y en a dans toutes les langues vivantes.. Alors d'accord, ce ne sera pas de l'espéranto académique qui lui restera génial, mais il n'empèche que des gens parleront espéranto "petit negre" tout comme on parle anglais "petit nègre" à l'heure actuelle, peut-etre moins distordu que l'anglais, va savoir, mais distordu quand même et avec toutes les incompréhensions que ça peut générer.
Exemple concret :
L'esperanto quoique tu en penses est une langue vivante parlée par de vrai gens qui converse de tout et n'importe quoi
En effet, tu as raison, ça m'apprendra à prendre wikipédia comme référence :)
D'après le dictionnaire de l'académie française (http://www.academie-francaise.fr/dictionnaire/(...) et http://atilf.atilf.fr/academie9.htm(...) ) :
Langue morte, qui n'existe plus que dans les écrits, par opposition à Langue vivante, qu'un groupe humain parle actuellement.
Quelque part c'est une excellente illustration des distorsions (ici elle est sémantique) dont je parle. D'après l'académie française (ceux qui spécifient la langue française) : est vivante une langue quand des gens la parlent. Soit...
Mais bon, je constate que ce n'est pas l'usage courant, le mien, celui de mon entourage et chez les gens de wikipédia. D'ailleurs, je parie que ce n'est pas le tien non plus, et que comme moi et contrairement au spécifications de l'académie française, tu n'appelleras pas le latin ou le klingon "langues vivantes". Pourtant => http://www.kli.org/(...) .
Il y a donc une source d'ambiguité, puisque ce mot n'a pas le meme sens pour les gens comme moi que pour les gens qui parlent le français académique. Marrant, ça ne vient carrément pas de la structure de la langue, ni de sa spécification qui elle me semble on ne peut plus claire...
Serait-ce parce que le français est une langue vivante ?
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 0.
----
Je ne vois pas en quoi ça remet en cause ce que je dis. Que Linux soit un OS facile à apprendre etc, sans doute... Pour ma part je le connais pas et je ne m'y interesse pas.
Ce que je dis c'est qu'actuellement, windows est déjà enseigné partout, qu'il est utilisé presque partout sufisemment pour qu'on se comprenne. Les windowsiens sont avantagés ? Tant mieux pour eux ! Je préfère voir un OS avantagée parmis d'autres que toute désavantagées. D'ailleurs, tu le dis toi même : Les personnes capables d'utiliser aussi bien un autre OS que l'OS sur le quels ils ont appris sont très rares. Quelle différence avec Linux/Windows/ce_que_tu_veux ?
Jusque là tout va bien
Mais bon, pour ma part, je n'utilise plus beaucoup windows, mais ce n'est pas pour ça que je tiens a imposer linux au monde sous pretexte que je le trouve plus adéquat et mieux foutu.
Si les unix-like ou le libre finissent par tourner partout, j'espere que ce sera parce qu'ils s'imposeront d'eux même, pas juste parce qu'on en a imposé l'usage. Idem s'ils doivent en venir a disparaitre : j'espere que ce sera parce qu'on en veut plus et non parce qu'on a tout fait pour les tuer.
Linux est un OS vivant, utilisé par plus de deux millions de personnes à travers le monde.
Là, c'est n'importe quoi. Je te parle d'une définition : une langue vivante est une langue qui est la langue NATALE de personnes encore en vie, cf http://fr.wikipedia.org/wiki/Langue_vivante(...) . Le concept d'OS vivant reste encore à définir. Ce qui rend cette partie du parallele totalement dénuée de sens.
Mais si ton paralelle me semble imparfait, c'est surtout parce que l'on parle d'une langue et non d'un OS, c'est sensiblement différent.
Un OS est un environnement informatique qui fournit des moyens à ses utilisateurs. On pourrait distordre le concet au point d'imaginer qu'un OS est un moyen de communication, mais même dans ce cas, il ne permet de communiquer que des concepts discrets, et il est prévu pour un contexte particulier : donner des information et recevoir des ordres, rien de plus.
Une langue est 'protocole' d'échange particulièrement évolué qui lui permet de faire passer une infinité de nuances et de concepts que n'atteindront pas de si tot nos dispositifs informatiques parce que c'est fait pour la communication entre êtres humains et sous toutes ses formes, pas uniquement pour une simple interaction ordre / information.
Maintenant, on peu considérer qu'un OS fournit un environnement et une culture qui ont peut-être une certaine ressemblance avec une langue parlée par des gens, mais ça n'a certainement pas la même importance à mes yeux dans la vie de tous les jours, et ça touche directement énormément moins de monde.
Ce que je peux tolérer avec un OS, je peux tres bien ne pas le tolérer avec quelque chose d'aussi omniprésent que le langage courant.
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 1.
Une bonne maîtrise, mais pas une manipulation comme si c'était ta langue natale.
La prononciation de l'esperanto a été fixé une fois pour toute.
Ce n'est pas pour ça que les gens vont la suivre. Pour exemple, la prononciation et le vocabulaire, en francais, ont aussi été aussi fixés, même si c'est plus complexe qu'en espéranto, semble-t-il. Ca n'oblige pas les gens à la suivre et avec le temps, pour ne pas être completement à côté de la réalité, l'académie française réajuste le tir en incluant les nouveaux mots et nouvelles prononciations.
Pour les exceptions je ne vois pas du tout en quoi cela serait un avantage
Ce n'est pas un avantage, c'est une caractéristique d'une langue vivante. Les gens rajoutent des mots, des tournures dans langue, et ces tournures introduisent parfoit des exceptions.
Donc, soit l'organisme ignore ces exceptions et crée des dialectes (la langue officielle est distinguée de la langue réellement parlée, celà fait au moins un dialecte), soit il inclue les exceptions pour rester proche de la réalité de la langue.
Justement si le contexte n'est pas clair, ou que l'on ne maitrise pas le sujet il est parfois difficile de comprendre.
Je suis sur que tu peux trouver ce type d'ambigüité quelle que soit la langue, y compris l'espéranto. Ne serait-ce que parce que l'auteur fait une figure de style.
Ah bon, par des personnes qui l'utilisent dans des discussions/courrier? Là tu m'étonnes!
Il y a 50 ans, oui, car c'était encore un signe d'érudition, il n'y a qu'a voir le nombre de gens qui ont appris le latin dans les 50 dernières années en France.
Ne serait-ce que les ecclésiastiques, qui le parlaient régulièrement dans les messes en latin.
Il est clair que maintenant, les gens capables de parler courrement le latin, ça doit pas courir les rues, pas plus que l'espéranto d'ailleurs.
Je trouve même que dire que l'Esperanto n'est pas une langue vivante est plutôt injurieux
Ce n'est pas mon but. Mais, que tu le veuilles ou non, il n'empeche que ce n'est pas une langue vivante, par définition. Remarque ce n'est pas une langue morte non plus car ça n'a jamais été une langue vivante.
De plus il existe des personnes (certes peu nombreuses) pour qui c'est la langue natale.
Je parie que je peux les compter sur une seule main :) De plus, je doute, vu la faible concentration des espérantophones (?), que ces personnes utilisent l'espéranto pour leur échanges humains quotidiens.
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 6.
Ce que je dis c'est qu'actuellement, l'anglais est déjà enseigné partout, qu'il est parlé presque partout sufisemment pour qu'on se comprenne. Les anglais sont avantagés ? Tant mieux pour eux ! Je préfère voir une langue avantagée parmis d'autres que toutes désavantagées. D'ailleurs, tu le dis toi même : Les personnes capables de parler aussi bien l'anglais que leur langue maternelle sont très rares. Quelle différence avec l'espéranto ?
la prononciation varie selon le pays
Justement parce que c'est une langue parlée partout. L'anglais comporte des règles précises (il suffit de prendre un dictionnaire d'anglais et tu as la prononciation en Queen's English, l'anglais académique) mais elles sont distordues selon les pays parce que les gens parlent la langue à leur sauce. L'espéranto aura très probablement le même problème si son succès augmente.
Je ne vois pas ce qui ferait que l'espéranto échapperait à cette tendance naturelle.
La déclinaison en dialectes d'une langue n'est clairement pas liée à sa structure mais à son usage (exemple : l'argot).
Même chose pour :
La grammaire est très simple, aucune exception.
Quelqu'un dans le thread à proposé d'enlever l'accent circonflexe de forêt, parce que c'était une source inutile d'erreur. N'est-ce pas une excellente illustration de modification des règles d'écriture dûe au caractère vivant de la langue ? Avant on disait "forrest" (cours ! cours !) , on écrivait un s, on s'est mis à dire "foré", on a remplacé le s par un accent, et maintenant, on considère qu'il n'est pas besoin de rattacher le mot à sa racine (on fait quoi pour forestier ?), on propose de virer l'accent.
Si l'espéranto était une langue vivante elle verrait fleurir néologismes et autres distortions du même type qui introduiraient assurément et rapidement les exceptions qui manquent à l'espéranto, tant au niveau grammaire qu'au niveau vocabulaire.
l'anglais est une langue parfois très vague
Soit c'est voulu, soit c'est mal exprimé. Si tu veux bien te faire comprendre, tu peux, même si tu n'as pas le vocabulaire nécessaire : le contexte est là pour ça. Je ne parle pas l'anglais couremment mais je n'ai que très rarement eu de problèmes d'ambiguité, comme quoi ce n'est pas si difficile à maîtriser en tant que langue internationale. Quelque soit la langue, tu auras toujours des ambiguités si la personne en face le désire ou s'exprime mal.
L'espéranto est une langue vivante, parlé par plus de deux millions de personnes à travers le monde.
Alors là je dis non ! Le latin est parlé par plein de monde, ce n'est pas ça qui en fait une langue vivante. Une langue vivante c'est une langue natale, utilisée courremment au quotidien par des gens qui l'ont apprise dès leur plus jeune age, ce qui fait qu'elle évolue au fil du temps ( http://fr.wikipedia.org/wiki/Langue_vivante(...) ). Ce n'est pas le cas de l'éspéranto.
D'ailleurs, si c'était le cas, l'espéranto se déclinerait rapidement en dialectes et deviendrait une langue comme les autres, difficile à maîriser, surtout quand ce n'est pas la langue natale.
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 2.
Pas dans l'utilisation d'une langue commune : les gens parlent la langue commune pour des rapports internationaux (enfin, plutot interlinguistiques :)), et continuent à parler dans leur langue natale le reste du temps. Je ne checke pas les news et pourtant je parle plus ou moins anglais.
on pourrait facilement désambiguer "free"
Ce serait pour créer d'autre ambiguités...
Je ne comprend que le français, l'anglais et un peu d'allemand et de japonais mais je sais qu'une suite de deux mots peut façilement être ambigüe au même titre que free software, quelque soit la langue.
Exemple en français : bière fraiche => je parle du cerceuil ou de la boisson ? La seule chose qui te permet de la savoir c'est le contexte : tu sais que socialement, en France, parler de bière fraiche au sujet d'un décès c'est quelque chose d'incongru et de culturellement répréhensible. Pour ces raisons, je pense qu'une langue sans culture ne peut permettre de s'exprimer aussi finement qu'une langue basée sur une culture.
Un mot amène un poid, une direction à la discussion, que tu modères ou accentues en fonction de ta culture, de ce que tu comprend de la culture associée à la langue, et du contexte discuté. Une langue nouvelle ne changera pas ça et pire encore, elle ne le permettra pas.
Et puis, en admettant qu'il existe une langue où chaque concept aurait une racine propre et distincte, afin d'éviter les ambiguités, où le contexte ne tiendrait pas un rôle majeur, cette langue aurait un vocabulaire tellement riche qu'elle ne serait pas humainement utilisable car il faudrait des années pour maitriser son vocabulaire. Ou alors, il lui manquerait tellement de concepts qu'elle serait très limitée dans son usage.
Pour le coté inaudible, j'avais lu un article (je ne sais plus où) sur une étude où l'on tentait d'expliquer pourquoi les francais sont des cancres en langues.
Et l'aspect culturel, il est pris en compte ? Ne serait-ce pas lié aussi au fait que les Français ont jusqu'a peu été une puissance dominante et qu'ils sont un peu réticents a admettre qu'ils ne sont plus qu'une puissance moyenne ? Le français a été la langue diplomatique pendant des années, et maintenant ne serait-ce pas réaliste de considérer qu'on a un peu de mal a s'adapter à la nouvelle donne ?
Les Japonais ont le même problème de langue que nous (il n'y a qu'a entendre un japonais parler anglais ou allemand...), et comme par hasard, ils ont été aussi nombrilistes que les français jusqu'a la fin du 19eme sciecle...
Sans parler des méthodes d'apprentissage... Ce qui m'a fait comprendre l'anglais, c'est de lire de l'anglais, ce n'est clairement pas les cours au lycée où en fac.
A mon avis, le coup du spectre ça doit jouer, mais ce n'est certainement pas la seule raison.
[^] # Re: Ordre du jour ?
Posté par Toufou (site web personnel) . En réponse à la dépêche Brevets logiciels : nouvelle offensive surprise. Évalué à 4.
L'anglais ou l'espagnol sont les deux langues européennes les plus répandues dans le monde. En Europe, je parie qu'il y a plus de gens qui parlent ou bargouinent l'anglais que l'espagnol, et je comprend tout à fait que nos députés européens aient préfèré et imposé l'anglais.
Un des nombreux avantages de l'anglais sur l'espéranto, c'est que tu peux t'immerger dans un milieu anglophone pour arrêter de parler un anglais bizarre : c'est une langue vivante.
Bref, utiliser l'espéranto reviendrait à limiter encore plus l'accès aux documents de ce type puisqu'une minuscule minorité de gens seulement le parle. Et je ne vois pas l'intéret d'investir de l'énergie pour faire apprendre une langue qui n'a jamais servi et qui ne sert pas actuellement, surtout pour remplacer une langue réelle qui a fait, et fait encore très bien l'affaire.
Maintenant, si on devait choisir une langue détachée de toute nationalité, je voterais pour le Noir Parler de Morgul, vu l'europe qu'on se prépare et vu les méthodes utilisées pour la mettre en place...
[^] # Re: FarCry et OpenGL
Posté par Toufou (site web personnel) . En réponse au journal Half-Life² sous Linux. Évalué à 2.
Entierement d'accord mais tant qu'a y être, autant prendre le moteur de rendu livré avec le moteur physique, surtout quand il a bonne réputation et qu'il n'y a pas besoin de le déployer (en théorie) puisque intégré à l'OS.
Si directX est plus connu c'est qu'il date de 1995 alors que SDL date de 1998. Il a aussi profité d'une réclame efficace.
Mouais, enfin, c'est surtout qu'il est fait par et pour MS, que c'est de bonne qualité, qu'il est installé de base (avec support de mise à jour par win-update) avec la plate forme dominante pour le jeu sous PC.
Par ailleurs à l'époque les cartes qui implémentaient efficacement openGL étaient très cheres alors que directX permettait de faire de la 3D logiciellement de manière efficace.
Quand DirectX a vraiment percé (version 3.0), les cartes grand public supportaient les accellérations matérielles : 3dfx, g200... Ce n'était pas donné pour le pékin moyen, mais c'etait complètement dans les prix du hard core gamer (et même moins cher que les cartes haut de gamme actuelles : 1200FF une 3dfx à sa sortie contre 300 euros la GeForce 6800, par exemple)
[^] # Re: Clarifications diverses et rapides.
Posté par Toufou (site web personnel) . En réponse à la dépêche L'accord à l'amiable entre BSDi et USL (AT&T) enfin public.. Évalué à 3.
Le modèle de vente de licences d'utilisation de logiciels est un modèle foireux justement parce que ça dérive sur ce que l'on peut constater de nos jours : plus d'argent injecté dans le droit et la pub que dans la recherche et développement.
Je pense que plus ça va aller dans ce sens, plus une la survie d'une petite société éditrice deviendra difficile puisqu'elle n'a pas les ressources nécessaires pour investir dans le droit. Et comme elle "vole" forcément la "propriété" des autres sociétés (le clic, la fenetre, le nom, etc) et dès qu'elle grossit un peu trop, elle est devient la cible de procédures judiciaires ce qu'elle ne peut pas se permettre....
Le juste milieu du marché du soft c'est la vente de services, et ça, ça prend du temps a être compris, mais ça viendra bien un jour : il n'y a pas d'autre choix :)
[^] # Re: Clarifications diverses et rapides.
Posté par Toufou (site web personnel) . En réponse à la dépêche L'accord à l'amiable entre BSDi et USL (AT&T) enfin public.. Évalué à 3.
Et ça c'est quoi : http://www.sigmadesigns.com/products/RMP4_video_codec.htm(...) ? MS a rencontré des problèmes avec un logiciel de softimage qu'ils ont racheté : http://www.zdnet.fr/actualites/technologie/0,39020809,2136648,00.ht(...) . Eux mêmes ont été dégagés de toute responsabilité mais softimage a perdu le procès : http://www.zdnet.fr/actualites/business/0,39020715,39127587,00.htm(...) .
Les gens qui font du proprio piquent aussi, volontairement (sigma) ou non (MS), du source chez les autres, et sont tout aussi exposés au procés et autres complications juridiques.
Bref, tu es emmerdé pareil sinon pire, vu que tu risques nettement moins si tu pompes du source libre pour produire du libre : la puissance du copyleft en action :)
[^] # Re: FarCry et OpenGL
Posté par Toufou (site web personnel) . En réponse au journal Half-Life² sous Linux. Évalué à 2.
Ton argumentaire me fait penser à : 10 milliards de mouches ne peuvent toutes se tromper : mangeons de la merde !
Si on n'utilise pas beaucoup DirectX dans les applications pro (genre ce que pixar peut utiliser, par exemple), au hasard, serait-ce à cause du fait qu'OpenGL serait plus adapté aux application de modélisation / rendu hyper réalistes et DirectX orienté vers l'animation et modélisation du monde (pas seulement moteur graphique mais aussi physique) ?
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tu as expliqué ce que tu pensais en disant : "interfacer une ligne de commande c'est faire n'importe quoi". Ca me gène dans le sens ou parfois c'est une très bonne solution. Maintenant, je suis d'accord avec toi sur le fait que faire ça systématiquement est une mauvaise approche.
Il est évident que d'utiliser ce principe pour de l'intéractif, ce n'est pas très malin. Je n'arrete pas de le dire... Dans ce même ordre d'idée, en ce moment, ce qui me chagrine c'est qu'on essaye de remplacer les applis C/S par des applis web. Pourtant, le web est encore moins interactif que la ligne de commande puisque le serveur ne peut rien envoyer spontanément au client : impossible de notifier sans faire crado un changement dans les données aux clients, par exemple : inadapté pour certaines situations.
Pour ce qui est des programmes irremplaçables, il est clair que ce serait peut-etre mieux de les avoir sous une autre forme, parce qu'ils permettraient sans doute de mieux répondre aux évolutions des besoins. Maintenant qu'on a le programme, on lui en demande plus.
Mais, l'informatisation est un processus itératif et les besoins évoluent sur la base existante. Avant, il n'y avait rien, les besoins c'était d'aboir un outil qui fasse le boulot. Maintenant qu'il y a un outil qui fait le boulot, on lui demande de le faire différement ou de faire des choses en plus. Les premiers développeurs n'ont pas fait n'importe quoi : ils ont répondu aux exigences qu'on leur a fixé. Il me semble compréhensible qu'ils n'aient pas eut en tête les besoins modernes, surtout quand le projet remonte à une époque ou l'interface graphique était atypique (cette fameuse époque où la ligne de commande était reine).
Mais, on peut se poser la question suivante : pourquoi ne remplace-t-on pas ces programmes ? L'effort de développement ne serait-il pas trop cher payé pour le gain ?
J'ai pris pour exemple le cas de cdrecord/gcombust parce qu'il me semble assez représentatif : pas top niveau ergonomie mais ça grave bien et suffisement simplement. Le rapport effort de développement / gains n'est peut-être pas encore assez interessant pour que quelqu'un en fasse une lib de gravure.
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tu n'as pas l'impression que tu rales parce qu'un logiciel ne répond pas a ton besoin ? Tout ce passage c'est : comment je fais ci ou ça avec ? La réponse est : tu ne le fais pas vu que ce n'est pas fait pour ça.
Tu aurais une lib de gravure avec juste gboolean burn(char* isoname) ça serait le même problème. Ta critique porte sur les fonctionnalités de cdrecord, non pas sur les techniques utilisées par son interface pour communiquer avec.
(..)C'est juste une question de bonne pratique(...)
Oui, dans le but de maintenir le machin et d'en faire quelque chose d'évolutif. Parfois, on fait un truc tout con qui répond juste a un besoin et alors, la bonne pratique est de faire simple. Ensuite, la séparation peut tres bien etre faite, au moins au niveau source. C'est juste que tu n'as pas envie de te taper les contrôles inhérents à la création d'une lib parec que tu ne programme que pour une ligne de commande.
ce que je dis s'applique également aux fichiers de conf sous Unix/Linux en général (...)à parser par une application tierce-partie
Il ne t'est jamais venu a l'idée que ce n'etait pas fait pour ? Encore une fois, tu rales parce que tu essayes d'utiliser un outil dans un contexte pour lequel il n'a pas été fait (typiquement, le fait de parser des fichiers config automatiquement alors qu'ils ne sont pas faits pour ça).
Les config XML c'est l'inverse. Avec VI, le XML c'est infect et illisible. Normal ce n'est pas fait pour ça.
Dans un cas c'est documenté, pas dans l'autre.
Si le gars ne documente pas, commande ou lib, tu es dans les deux cas dans la mouise. C'est un probleme de doc, pas de techno.
C'est pas un peu très idiot ?
Pas plus que de transformer un appel interne du front end en un appel à une lib. LA lib traitera aussi les parametres pour s'assurer qu'ils sont valables et accesoirement, les transformera peut-être pour ses besoins internes.
Le principe est le même : c'est une transformation des parametres transmis au frontend pour l'envoyer vers le truc qui va éventuellement les transformer afin d'éxecuter sa tache avec les bons paramètres.
Il n'y a que le chemin technique qui differe. Dans certains cas, c'est plus facile par du code, dans d'autres c'est plus facile via une ligne de commande.
Juste pour la précision (...) je ne vois pas en quoi celà va dans ton sens
Je n'ai cité ça que pour illustrer le fait que, comme mes autres exemples, quand les methodes lègeres sont sorties du panier, elles etaient souvent présentées comme LA solution à tous les problèmes. Comme toujours, on en est revenu et on les considère maintenant que comme un des outils pour gérer un projet, au même titre que les autres méthodes. On choisi de les utiliser ou pas en fonction du contexte du projet, pas uniquement parce que çai mieux (tm).
La ligne de commande comme IPC, n'est pas plus que la librairie, l'interface ultime, même si d'après toi elle a été présentée comme tel. En tous cas, je n'ai jamais affirmé que c'était LA solution, je dis juste qu'il est crétin de la bannir sous prétexte que çai mal (tm).
Oui effectivement, seulement si il a les sources.
Oui evidemment :) De toutes façons, si tu n'as pas les sources, lib ou commande, tu feras très probablement des trucs porky si tu veux étendre les fonctionnalités de l'outil, parce que tu ne pourras faire les ajustements nécessaires dans l'outil pour qu'il prenne en charge tes nouvelles utilisations.
Celà peut être légitime(...)communication privilégié
1- je ne vois pas en quoi les chaines de caractères sont des formats à la con : c'est humainement compréhensible (contrairement à un hash, ou une structure/record ou autre type composite) et ça se génère et gère tres bien dans bon nombre de langage (je ne connais que le C qui rend leur gestion plus délicate).
2- un programme est fait pour être utilisé dans un but et dans un contexte. Il est évident que si ton programme n'est fait QUE pour des machines, il existe d'autres moyens que la ligne de commande et probablement plus adaptés. Maintenant, si tu veux quelque chose d'utilisable par des humains (une commande) et parfois, par des machines, la ligne de commande c'est une possibilité qui peut s'avérer plus interessante que les autres, particulierement dans le cas que j'ai cité : paramétrage d'un processus long et non interactif.
Comme je te l'ai indiqué plus haut, même pour ces 2 cas précis c'est insuffisant.
Non, ça joue le morceau que je demande, ça l'arrete quand je n'en veut plus ou quand il est terminé, le tout en mode graphique : ça fait ce pour quoi c'est fait.
il y a pleins de messages à parser si on vuet qu'il y est un tant soit peu d'interactivité.
Dans ce cas, on devrait utiliser une librairie :) Ce n'est pas très malin de passer par la ligne de commande si on veut de l'interactivité durant le traitement. Il me semble que je l'ai déjà dit avant.
Pareil pour la gravure, faut bien indiquer en permanence l'état des buffers, signaler des messages sur la vitesse courante de gravure...
Non, mon besoin c'est : je selectionne tous les paramêtres de la gravure graphiquement, je clique sur GO et quand c'est fini le frontend me dit "ça marche / ça marche pas" en fonction du résultat : la ligne de commande c'est nickel pour ça.
Si tu as les besoins que tu cites, alors oui, utilises une lib.
Euh, dans le cas de la lib, il n'y a pas de vérification de débordement à faire
Beh si. Il te faut coder ta lib béton parce que l'utilisateur de la lib peut t'envoyer du yahourt. Si je fais un burn(NULL), et que tu ne testes pas dans burn() tes paramètres d'entrée, alors segfault. Si j'ai une fonction burn() identique dans un programme et pas en lib, je n'ai pas besoin de faire ce test, parce que je sais que je n'y enverrais jamais NULL si je sais que j'ai fait le controle en amont.
Evidemment, ce n'est qu'un exemple, mais ce n'est evidemment pas le seul et puisque tu demande un truc indépendant du langage (d'ailleurs, le débordement de buffer ce n'est pas spécifique au C), en voila un autre :
Toujours en restant sur l'exemple de la gravure, tu dois vérifier dans burn() que le device cible existe bien, ou au moins gérer l'erreur si l'utilisateur de la lib envoie n'importe quoi. Si c'est une fonction intégrée un programme complet, ce n'est pas forcément nécessaire si tu as fait le controle en amont (si l'utilisateur n'a qu'un choix limité, par exemple).
De toutes manières c'est hors sujet.
D'ailleurs, il me semble bon de rappeller, au milieu de ce troll, que le sujet n'est pas "la librairie c'est mieux". Le sujet est "c'est abérrant d'utiliser des redirections d'I/O dans des programmes". Mon propos est : "parfois les redirections d'I/O c'est plus adapté qu'une API" et le tien, si je l'ai bien compris est : "dans tous les cas, il devrait y avoir une API et on ne devrait jamais utiliser la redirection I/O comme ipc".
plutôt des habitudes du passé, qui se sont transformées en boulet avec le temps, parcque les technos étant dépassées.
Ce ne sont pas que des habitudes : les mecs qui utilisaient ça plutot qu'autre chose le faisaient de manière aussi réfléchie que maintenant. Certaines de ces réflexions ne sont peut-etre plus valables aujourd'hui, d'autres le sont encore.
Et puis, dépassé, ça veut dire quoi ? Qu'on a forcément mieux dans tous les cas avec une techno plus moderne ? J'aimerais bien y croire. Ce que tu gagnes quelque part sur une techno réfléchie (même vieille), tu le perds généralement ailleurs. La polyvalence et la simplicité d'une redirection d'I/O contre la puissance et l'exclusivité d'une API....
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Tout a fait, mais dans certains cas (les cas que j'ai cité en exemple), le résultat c'est "ça marche" / "ça ne marche pas". C'est pas trop la mort à parser, et les perfs ne sont pas importantes.
Sans parler de l'absence de tous les protocoles spécifiques à la communication entre programmes : types de données, exceptions, synchronisation, etc.
C'est sur, mais bon, pour lancer un mp3 ou une gravure, on va peut-etre pas non plus faire une norme ISO hein ? :) De plus, il y a plein de domaines ou il n'y a pas de protocole consensuel ou standard. Quelle différence il y a entre une API maison ou une ligne de commande maison ?
Sans parler qu'il a création inutile de processus quand un simple thread suffirait voir rien du tout.
Si les ressources systeme ne sont pas des ressources critiques, je ne vois pas le mal qu'il y a à créer un processus supplémentaire.
Non effectivement on a inventé celà y'a 20 ans, en croyant qu'on allait pouvoir tout faire avec ça
En 20 ans, on a lancé d'autres modes diverses et variées en croyant qu'on pouvait tout faire avec :
- tout stocker avec une approche relationnelle (même les fichiers !)
- tout stocker en XML (même les fichiers config !)
- tout faire avec une approche modulaire
- tout faire avec une approche l'objet (aaaah les BD objets :) )
- gérer tous les projets avec des methodes lourdes (sauce RUP)
- gérer tous les projets avec des methodes légeres (sauce XP)
- faire toutes les interfaces graphiques
- rendre tabou le goto
- passer toutes les applications C/S sur des technos Web
- tout faire passer par le port 80
- tout sortir du noyau
- etc., etc....
L'erreur n'est pas dans la techno mais dans le fait qu'on pense tout résoudre (et en mieux en plus) avec une seule approche. Si à chaque fois qu'on trouvait la méthode / techno universelle de la mort qui tue, ses évangélistes donnaient 10¤ à l'ONU, on pourrait s'acheter la paix dans le monde :)
Une approche unique ne convient pas à toutes les problématiques. S'interdire des approches c'est se compliquer la vie dans les cas où l'approche n'est pas appropriée. Et moi, je n'aime pas me compliquer la vie quand ce n'est pas nécessaire.
de nombreux programmes ont été conçus sans du tout penser à proposer une interface de programmation plus avancée EN PLUS
Je vois pas pourquoi j'irais faire une interface de programmation plus avancée EN PLUS si celle que j'ai répond à mon besoin. Si quelqu'un utilise mon programme, soit il a les mêmes besoins que moi (et l'interface existante devrait lui convenir), soit il a des besoins proches mais pas identiques et ce n'est pas à moi de résoudre ses problèmes : il prend mon programme et en fait une lib s'il a besoin d'une lib.
bref c'est valable pour la plupart des GUIs
Je n'ai jamais dit le contraire. Mais bon, la plupart ce n'est pas toutes. J'ai cité 2 exemple qui sont tout à fait convenables en termes de GUI et qui marchent très bien comme ça.
mais je cherche toujours les avantages de n'avoir QUE une interface console
Ca me semble évident : du moment que ça répond au besoin, tu t'embetes pas a faire une lib et/ou un composant : tu peux ne gérer que tes cas à toi, ce qui n'est pas le cas d'une lib ou d'un composant.
Par exemple, tu ne vas pas gérer un débordement de buffer dans ta lib parce que ce sera controlé en amont, au parsing de la ligne de commande par exemple. Si tu fais une lib ET une commande, tu devras probablement te taper deux fois le controle : au parsing des arguments ET à l'entrée de la fonction qui traite un des arguments, sinon tu risques le segfault dans l'une ou l'autre partie de la chaîne.
En tout cas tu confirmes ce que je disais : pour linux aussi les habitudes des utilisateurs sont un vrai boulet à traîner.
Je pense que tu n'aimes pas les mêmes gens que moi : les gens qui fustigent une techno et qui sont des boulets à cause de leur inaptitude a s'adapter au but parce qu'il sont limités à une seule approche.
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Et puis, la perte de perf n'est vraie que pour la génération des parametres et le passage de ces paramètres. C'est un parametre parfois critique et il vaut mieux éviter la commande si tu lances beaucoup de fois le processus et que ce processus est rapidement traité : dans ce cas, la lib va bien mieux, c'est clair.
L'autre limitation de l'utilisation d'une commande c'est que ce n'est pas le pied pour un processus interactif, dans ce cas, c'est sur qu'il vaut mieux éviter.
Mais sinon, si tu lances un processus long qui n'est pas interactif, interfacer une commande va tres bien (cdrecord / gcombust ou mpg123 / frontend quelconque, par exemple), et je ne vois pas ce qu'amènerai de plus l'utilisation d'une lib.
[^] # Re: oué et
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 3.
Je ne vois pas ce qu'il y a d'absolument aberrant la dedans ...
Sur le principe c'est plus ou moins la meme chose qu'un machin tout intégré a la sauce composant ActiveX ou KPart, ou que l'utilisation d'une dll. C'est le principe du découpage des taches et de la ressource partagée: la commande ou le composant execute une tache plus ou moins bien découpée et on le commande par une interface plus ou moins bien définie. De plus, plusieurs programmes peuvent utiliser cette ressource sans avoir besoin d'en réinstaller une équivalente.
Ca a même l'avantage de pouvoir tourner sans interface additionnelle (puisque c'est déjà intégré dans la commande shell), alors que ton composant, tu aura forcément besoin d'une interface additionnelle pour en tirer quelque chose. Sans compter que généralement, les dépendances des composants sont très nettements suppérieures à celle d'une commande shell.
Inversement, c'est pas gagné pour faire du glisser graphique avec une commande shell :)
M'enfin d'un point de vue technique, utiliser une lib player mp3 et l'intégrer dans un programme graphique, utiliser un composant player mp3 et l'intégrer dans une interface graphique ou piloter un mpg123 like par une interface graphique, c'est un choix qui se fait en fonction de ce qu'on veut faire et qui n'est aberrant qu'en fonction de ce qu'on a voulu faire.
D'un point de vue utilisateur, du moment que ça répond au besoin, on se contrefout de comment c'est fait...
[^] # Re: Windows plus lourd que Linux : fausse légende urbaine !
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 1.
[^] # Re: Windows plus lourd que Linux : fausse légende urbaine !
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 0.
Active le DMA sur tes disques sous linux.
[^] # Re: ton argumentaire est périmé.
Posté par Toufou (site web personnel) . En réponse au journal Windaube, c'est maaaaaal! / linux c'est bien!. Évalué à 4.
Beh mon expérience c'est totalement le contraire :
Au boulot, j'ai un celeron 700 bousesque (un HP vectra) avec 192Mo de RAM. Sous Win98SE : reboot plusieurs fois par jour pour cause de manque de RAM (je ne sais pas pour XP ou 2000, mais 98 ne supporte pas d'être juste en RAM). Ouvrir un truc comme Eclipse sous windows avec word ouvert c'est le reboot assuré dans l'heure qui suit. Ce n'est pas le cas d'eclipse et de OO sous nux.
Du coup, j'ai installé une slackware 9.0 à sa sortie et depuis je ne bosse qu'avec ça (messagerie, gestion du serveur applicatif que je dois maintenir (code/config), production de doc / rapports sous OO).
Depuis ce temps là, je ne reboote plus ma machine en journée pour cause de plantages, et niveau rapidité, c'est pareil que pour windows en terme de démarrage d'application (sauf OO sous nux qui est plus lent que Word 2000 si ce sont les seules applis lancées).
La différence se ressent surtout dès que tu commence a avoir plusieurs applis lancées en même temps (ce qui est toujours mon cas), particulierement au changement d'application (le ALT+TAB quoi) : sous linux, le passage de moz mail a OO, c'est quasi immédiat. Sous windows, pour passer de moz mail à Word, c'est tres nettement supérieur à 30 secondes. L'ouverture d'applications sur un nux chargé reste correcte (OO et moz ouverts, Vim démarre en 2/3 secondes maxi) alors que sous windows ça se dégrade très très vite (moz et word 2000 ouverts, le notepad démarre en plus de 10 secondes).
Bref chez moi :
- un explorateur de fichier (...) : Midnigth Commander, aussi ergo que explorer meme s'il peut paraitre moins beau, nettement plus rapide et surtout 200 fois plus stable !
- une suite bureautique qui tourne (...) : OO 1.1. Sous windows ou sous nux, elle ouvre plusieurs documents sans planter, ce n'est pas le cas de MS-Office sur mon poste. Sous nux, elle marche moins bien (quelques bugs d'affichages, entre autres) mais au niveau reactivité dans un environnement chargé, c'est sans commune mesure avec Word.
- un navigateur qui ne met pas 3 plombes à s'allumer : vu que j'ai tout le temps le client de messagerie de moz ouvert, avoir un navigateur me prend moins de 3 secondes a vide, et moins de 10 secondes si j'ai OO d'ouvert. Sous Window, moz est plus rapide et moins instable qu'IE en environnement chargé (avec le client mail moz ouvert).
Pour résumer, entre les deux OS et sur une machine qui a 3/4 ans, bosser sous win est une plaie pour des problèmes de perfs et de stabilité, alors que sur un nux pourtant plus récent (et donc sensé être plus gourmand) la réactivité est correcte et la stabilité sans reproche. Cela vient peut-etre de l'antivirus, je n'en sais rien, mais c'est un fait.
Note que j'ai volontairement ignoré les problemes de virus et autres spywares que je n'ai plus depuis que je bosse sous nux, alors que mes collegues ....
[^] # Re: Groumph !
Posté par Toufou (site web personnel) . En réponse au journal Bush gagne.... Microsoft se prépare à perdre. Évalué à 2.
Il peut être nécessaire de laisser l'utilisateur admin de sa machine justement pour installer des softs (les informaticiens par exemple), vu que tu n'as pas les ressources pour assurer cette gestion. Perso, ça ne me dérangerais pas qu'on m'enleve les droits admin (j'aimerais bien en fait) de ma machine mais bon, je plains les gars de l'infogérance qui vont devoir intervenir dessus toutes les deux minutes :)
D'un autre côté, ce n'est pas facile d'imposer à un key people le fait qu'il ne doit pas installer ses cochonneries sur le portable qu'il s'est fait acheter par la boite.
C'est peut-être débile d'un point de vue sécu mais bon, la sécu ce n'est pas non plus une fin en soi et si elle gène trop l'utilisation, il me semble logique qu'on la mette de côté : tout le monde ne fait pas dans le top secret, t tant que les virus ne font que gèner, on peut s'en accommoder.
[^] # Re: Une remarque à ce sujet...
Posté par Toufou (site web personnel) . En réponse au journal Copie pirate légalisé. Évalué à 2.
La copie privée te permet de copier tout et n'importe quoi pour ton usage privé, hors logiciels et bases de données qui ont été exclus en 86, si je ne me trompe pas (attention toutefois à ne pas violer l'EUCD français qui, il me semble, a été intégré dans la LCEN).
Les auteurs de ce tout et n'importe quoi ont donc un manque à gagner et pour compenser, l'etat prelève une redevance sur les supports numériques qui sont très probablement déstinés a recevoir cette copie : CD / DVD vierges et disques dur d'appareil de reproduction multimédia (magnétoscopes numériques, probablement aussi les RAM des baladeur MP3.
Normalement, cette redevance est ensuite distribuée aux sociétés de gestions des droits de leurs adhérents : SACEM mais aussi surement l'équivalent pour les films.
Je crois que c'est distribué en fonction des ventes de chacun, mais je n'en suis pas sur.
Je ne suis pas juriste, mais à force de lire et relire les textes qui parlent de ça, je crois que je ne dois pas être trop à coté de la plaque. Si un pro de la loi peu confirmer ou infirmer, qu'il ne se gène pas :)
[^] # Re: Please pas de troll politique
Posté par Toufou (site web personnel) . En réponse au sondage Qui qui va gagner les nélections ?. Évalué à 6.
Ché où qu'on chort ?
[^] # Re: Brevet
Posté par Toufou (site web personnel) . En réponse au journal Psacal Lamy persiste et signe. Évalué à 2.
Bah y a Rocard, il me semble, et il n'est pas Vert non plus.
[^] # Re: La mauvaise raison
Posté par Toufou (site web personnel) . En réponse à la dépêche Linux de plus en plus présent en entreprise selon IDC, rapporte "Le Monde Informatique". Évalué à 2.
[^] # Re: La mauvaise raison
Posté par Toufou (site web personnel) . En réponse à la dépêche Linux de plus en plus présent en entreprise selon IDC, rapporte "Le Monde Informatique". Évalué à 3.
Mais ça n'enleve pas les soucis de compatibilités avec les standards dans le libre, même s'ils ne sont que des questions de temps... Tiens dans la série des exemples, j'aurais pus aussiciter les linux threads, qui se sont aussi beaucoup améliorés mais qui divergent toujours du standard sur la gestion des signaux...