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...
Et puis meme pour les logiciels proprietaires, y'en a qui sont abandonnes. la visibilite n'est pas un argument, ni en faveur du libre ni en faveur du proprietaire.
100% d'accord. Toutefois, l'independance vis à vis des editeurs proprios est quand même une des plus grosses forces du libre (comme par hasard, elle découle directement des 4 libertés qui font si peur que les journalistes les énumèrent rarement).
le respect des standards
Ca c'est l'argument pro-LL que je trouve le plus fallacieux et pourtant, on le cite régulièrement. Beaucoup de softs proprios respectent les standards aussi bien, voir mieux, que leur équivalent libre. Pour exemple, Oracle ou même MS-Access (oui oui, Access) sont plus respectueux de SQL que mySQL qui est le plus répendu et connu des SGBD libres (ouais bon, il existe heureusement Postgres) et ça m'etonnerais qu'IIS ne respecte pas http aussi bien qu'Apache et Mozilla a aussi ses délires avec le HTML / CSS.
L'avantage du libre c'est plutot que lorsqu'il ne respecte pas les standards, c'est rarement dans le but d'éliminer toute forme de concurrence.
L'internet d'entreprise, c'est pas l'Internet kikoolol, c'est juste un outil de travail.
Ouais, mais il faut arreter de croire que les employés sont des robots. Personne ne travaille 100% de son temps de travail officiel. En tous cas, j'ai toujours vu glander hors pause officielle (secteur privé ou public, toute discipline et tous niveaux rencontrés). On n'est heureusement plus au début du 20e sciecle, ou tu n'avais que 15 minutes de pause midi, dans ta journée de 12h, 6 jours sur 7.
Comme l'a dit quelqu'un au dessus, du moment que les gens font leur boulot et ne dérangent pas les autres, je ne vois pas pourquoi on irait les ennuyer (sauf si la boite paye le net au volume), et les empêcher d'aller se balader sur le net. Que ce soit du cul ou du sport, ou les cours de la bourse ne devrait pas faire de différence : c'est un une tolérance totalement subjective. La seule chose qui importe c'est que le gars fasse son boulot et n'engage pas la responsabilité de la boite dans un 'surf' illégal.
Mouais je trouve ces définitions plutot discutables et l'argumentation particulierement mal vue.
Pour ma part, je dirais que :
- un bug c'est une erreur de programmation (parfois de paramétrage) qui amène un comportement non prévu par les concepteurs du logiciel (pas obligatoirement un plantage brutal, c'est souvent moins flagrant).
- et une faille de sécurité, c'est la possibilité d'exploiter une particularité d'un dispositif informatique (dont les bugs) a des fins malhonnètes : les coordonnées perso ou la copie de la RAM dans un .doc, l'exécution systématique d'un .vbs dans un mail ne sont pas des bugs (puisque c'est fait exprès) pourtant, ce sont des failles de sécurité (et encore, ça dépend du contexte).
Et puis, le plantage brutal d'une application est suffisement rentré dans les moeurs de l'utilisateur moyen pour ne plus être considéré comme un comportement anormal mais seulement gènant : "zut, mon XXXXX a encore planté, il va falloir que je recommence".
Ok, mais ça ne fait jamais que permettre la constitution de fichiers de "contrevenants", ça ne legalise pas les moyens de le constituer. A mon avis le seul moyen de constitution légal d'un tel fichier hors procédure, c'est le pot à miel.
Il existe d'ailleurs des réseaux p2p privés qui permettent d'éviter ce type de risque et d'ailleurs les majors n'ont pas l'air d'apprécier (je ne retrouve plus la niouze que j'avais vu la dessus). Le truc rigolo c'est que si les membres de ce type réseau se font choper, ça doit relever du traffic en bande organisée et ça doit donner des bonus +2 ans pour la peine de prison :)
Par contre il faudrait enlever cette stupide taxe sur les supports de stockage à ce moment là, parce que sinon ca va faire double emploi.
Il me semble que ça n'a rien à voir :
les CD / DVD / cassette et disque dur sont des moyens de stockage de contenu et le net un moyen d'accès.
Tu peux très bien stocker sans utiliser le net pour y accèder donc la redevance sur les supports semble justifiée (si on considère qu'il est juste qu'elle existe).
Tu peux tout aussi bien utiliser le net sans utiliser de moyen de stockage taxé (il me semble que les disques dur informatiques ne sont toujours pas soumis à la redevance, uniquement ceux des dispositifs audio/vidéo).
oui, des ptits malins, parce qu'être payé pour regarder avancer le baudet toute la journée
Il me semble qu'il n'est toujours pas permis de scruter le trafic personnel sans la demande d'un juge dans le cadre d'une procédure judiciaire, ce qui fait que les petits malins qui scrutent la mule n'ont aucune valeur légale et se mettent même en danger en risquant des poursuites pour violation de ta vie privée.
La seule possibilité qu'auraient ces petits malins pour scruter ton activité hors procédure judiciaire serait qu'ils posent un pot à miel (avec le bon warez dedans) et que tu te fasse gauler la main dans le sac. Mais bon, la légalité d'un pot à miel reste à prouver.
Donc, hors procédure judiciaire, il n'ont aucun moyen de distinguer les fichiers légaux des fichiers illégaux et la présomption d'innocence devrait faire le reste pour te rendre plus blanc que neigne.
Résultat : aucun moyen de contrôle pour ce qui est de cette redevance avec les moyens actuels (sauf si je me goure dans les lois, ce qui est plus que possible : je ne suis pas juriste), ce qui rend cette redevance viable que si tu l'applique à tout le monde et donc injustement.
J'ai volontairement mentionné la Mandrake PowerPack justement parce qu'elle est payante et pas librement téléchargeable.
Je n'en savais rien et dans ce cas, je pense qu'il est clair qu'on reversera une partie de la redevance à Mdk pour sa distro.
En revanche, prenons un truc payant mais libre (la distro Machin) :
Machin permet le téléchargement de sa distro (entièrement libre) uniquement si tu payes. Si tu télécharges une distro Machin, disons sur bittorent parce que quelqu'un l'a mis en libre accès, va t'on distribuer une partie de cette redevance à Machin ?
La question exacte sera comme tu le dis : comment va-t-on redistribuer la redevance ? Sur le volume mis a dispo ? Sur la licence d'utilisation ? Sur la quantité de CD / DVD vendus par les circuits de distribution classique ?
Bref, quelque soit la méthode de calcul, je pense que c'est infaisable de manière juste et surtout la méthode la plus utilisée (distribution au prorata des ventes sur une distribution classique) tuera completement la concurrence. En effet, comment monter une société de distribution en ligne compétitive si les grosses boites qui ont un réseau de distribution classique bénéficient d'un apport financier que tu ne peux avoir (puisque que tu ne vends pas autrement) ?
Bref, si redevance il y a (et je pense qu'on l'aura, si les DRM capotent et donc que les majors changent leur fusils d'épaule), ce sera un truc aussi nase que pour la redevance CD / DVD => tout direct dans la poche des majors et des 'artistes' qui vendent beaucoup de supports physiques.
Pour ce qui est de la copie, selon ce meme texte, toute copie privee effectuee a l'usage prive du copiste est legale, point.
C'est bien ce que j'avais cru comprendre du texte : toute copie faite par ses propres moyens est légale (sauf pour les logiciels depuis une modif de la loi en 1986, si j'ai bien tout suivi et si je me rapelle bien). Ce qui est illégal c'est la mise en circulation de ses copies (ce que fait le P2P).
Donc emprunter (chez un loueur de cassettes / DVD ou une médiathèque) pour copier est une activité légale. Je crois que les loueurs / prèteurs payent justement une redevance exprès pour ce type d'usage de leurs prets / locations.
Ce que je ne savais pas c'est que le pret du CD par un copain etait légal, vu que je croyais que le cercle famillial etait restreint strictement à la famille.
Si tu partages ces fichiers ou si tu en télécharges (donc en détiens) de CDs que tu n'as pas achetés, la redevance s'impose.
Je peux tres bien détenir des fichiers que j'ai copié moi même depuis les CD / DVD que j'ai loué ou emprunté, et jusqu'à preuve du contraire ça relève aussi de la copie privée. Je n'utilise donc pas le net pour les télécharger et donc ne rentre pas dans le cadre de la redevance... Comment faire le distingo ?
Quand à l'aspect gratuit / payant, c'est clair que ça pose des questions rigolotes : la MDK est payante mais libre donc librement téléchargeable => donne-t-on une part de la redevance a MDK ?
Les oeuvres completes de Neos (je ne sais même pas ce que c'est mais admettons que ce soit un groupe de zik) sont gratuites (téléchargeables gratuitement sur leur site) mais pas libres (tu n'as pas le droit de les distribuer par exemple) : donne-t-on des sous au groupe ?
Bon courage aux législateurs :)
[^] # 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...
[^] # 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é à 4.
100% d'accord. Toutefois, l'independance vis à vis des editeurs proprios est quand même une des plus grosses forces du libre (comme par hasard, elle découle directement des 4 libertés qui font si peur que les journalistes les énumèrent rarement).
le respect des standards
Ca c'est l'argument pro-LL que je trouve le plus fallacieux et pourtant, on le cite régulièrement. Beaucoup de softs proprios respectent les standards aussi bien, voir mieux, que leur équivalent libre. Pour exemple, Oracle ou même MS-Access (oui oui, Access) sont plus respectueux de SQL que mySQL qui est le plus répendu et connu des SGBD libres (ouais bon, il existe heureusement Postgres) et ça m'etonnerais qu'IIS ne respecte pas http aussi bien qu'Apache et Mozilla a aussi ses délires avec le HTML / CSS.
L'avantage du libre c'est plutot que lorsqu'il ne respecte pas les standards, c'est rarement dans le but d'éliminer toute forme de concurrence.
[^] # Re: Et avec des vrais journeaux
Posté par Toufou (site web personnel) . En réponse au journal Proxy web volontariste. Évalué à 5.
Ouais, mais il faut arreter de croire que les employés sont des robots. Personne ne travaille 100% de son temps de travail officiel. En tous cas, j'ai toujours vu glander hors pause officielle (secteur privé ou public, toute discipline et tous niveaux rencontrés). On n'est heureusement plus au début du 20e sciecle, ou tu n'avais que 15 minutes de pause midi, dans ta journée de 12h, 6 jours sur 7.
Comme l'a dit quelqu'un au dessus, du moment que les gens font leur boulot et ne dérangent pas les autres, je ne vois pas pourquoi on irait les ennuyer (sauf si la boite paye le net au volume), et les empêcher d'aller se balader sur le net. Que ce soit du cul ou du sport, ou les cours de la bourse ne devrait pas faire de différence : c'est un une tolérance totalement subjective. La seule chose qui importe c'est que le gars fasse son boulot et n'engage pas la responsabilité de la boite dans un 'surf' illégal.
[^] # Re: Ça picote...
Posté par Toufou (site web personnel) . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à 5.
Pour ma part, je dirais que :
- un bug c'est une erreur de programmation (parfois de paramétrage) qui amène un comportement non prévu par les concepteurs du logiciel (pas obligatoirement un plantage brutal, c'est souvent moins flagrant).
- et une faille de sécurité, c'est la possibilité d'exploiter une particularité d'un dispositif informatique (dont les bugs) a des fins malhonnètes : les coordonnées perso ou la copie de la RAM dans un .doc, l'exécution systématique d'un .vbs dans un mail ne sont pas des bugs (puisque c'est fait exprès) pourtant, ce sont des failles de sécurité (et encore, ça dépend du contexte).
Et puis, le plantage brutal d'une application est suffisement rentré dans les moeurs de l'utilisateur moyen pour ne plus être considéré comme un comportement anormal mais seulement gènant : "zut, mon XXXXX a encore planté, il va falloir que je recommence".
[^] # Re: Idée
Posté par Toufou (site web personnel) . En réponse au journal Télécharger pas illégal?. Évalué à 2.
Il existe d'ailleurs des réseaux p2p privés qui permettent d'éviter ce type de risque et d'ailleurs les majors n'ont pas l'air d'apprécier (je ne retrouve plus la niouze que j'avais vu la dessus). Le truc rigolo c'est que si les membres de ce type réseau se font choper, ça doit relever du traffic en bande organisée et ça doit donner des bonus +2 ans pour la peine de prison :)
[^] # Re: Idée
Posté par Toufou (site web personnel) . En réponse au journal Télécharger pas illégal?. Évalué à 1.
Il me semble que ça n'a rien à voir :
les CD / DVD / cassette et disque dur sont des moyens de stockage de contenu et le net un moyen d'accès.
Tu peux très bien stocker sans utiliser le net pour y accèder donc la redevance sur les supports semble justifiée (si on considère qu'il est juste qu'elle existe).
Tu peux tout aussi bien utiliser le net sans utiliser de moyen de stockage taxé (il me semble que les disques dur informatiques ne sont toujours pas soumis à la redevance, uniquement ceux des dispositifs audio/vidéo).
[^] # Re: Idée
Posté par Toufou (site web personnel) . En réponse au journal Télécharger pas illégal?. Évalué à 1.
Il me semble qu'il n'est toujours pas permis de scruter le trafic personnel sans la demande d'un juge dans le cadre d'une procédure judiciaire, ce qui fait que les petits malins qui scrutent la mule n'ont aucune valeur légale et se mettent même en danger en risquant des poursuites pour violation de ta vie privée.
La seule possibilité qu'auraient ces petits malins pour scruter ton activité hors procédure judiciaire serait qu'ils posent un pot à miel (avec le bon warez dedans) et que tu te fasse gauler la main dans le sac. Mais bon, la légalité d'un pot à miel reste à prouver.
Donc, hors procédure judiciaire, il n'ont aucun moyen de distinguer les fichiers légaux des fichiers illégaux et la présomption d'innocence devrait faire le reste pour te rendre plus blanc que neigne.
Résultat : aucun moyen de contrôle pour ce qui est de cette redevance avec les moyens actuels (sauf si je me goure dans les lois, ce qui est plus que possible : je ne suis pas juriste), ce qui rend cette redevance viable que si tu l'applique à tout le monde et donc injustement.
J'ai volontairement mentionné la Mandrake PowerPack justement parce qu'elle est payante et pas librement téléchargeable.
Je n'en savais rien et dans ce cas, je pense qu'il est clair qu'on reversera une partie de la redevance à Mdk pour sa distro.
En revanche, prenons un truc payant mais libre (la distro Machin) :
Machin permet le téléchargement de sa distro (entièrement libre) uniquement si tu payes. Si tu télécharges une distro Machin, disons sur bittorent parce que quelqu'un l'a mis en libre accès, va t'on distribuer une partie de cette redevance à Machin ?
La question exacte sera comme tu le dis : comment va-t-on redistribuer la redevance ? Sur le volume mis a dispo ? Sur la licence d'utilisation ? Sur la quantité de CD / DVD vendus par les circuits de distribution classique ?
Bref, quelque soit la méthode de calcul, je pense que c'est infaisable de manière juste et surtout la méthode la plus utilisée (distribution au prorata des ventes sur une distribution classique) tuera completement la concurrence. En effet, comment monter une société de distribution en ligne compétitive si les grosses boites qui ont un réseau de distribution classique bénéficient d'un apport financier que tu ne peux avoir (puisque que tu ne vends pas autrement) ?
Bref, si redevance il y a (et je pense qu'on l'aura, si les DRM capotent et donc que les majors changent leur fusils d'épaule), ce sera un truc aussi nase que pour la redevance CD / DVD => tout direct dans la poche des majors et des 'artistes' qui vendent beaucoup de supports physiques.
[^] # Re: Idée
Posté par Toufou (site web personnel) . En réponse au journal Télécharger pas illégal?. Évalué à 2.
C'est bien ce que j'avais cru comprendre du texte : toute copie faite par ses propres moyens est légale (sauf pour les logiciels depuis une modif de la loi en 1986, si j'ai bien tout suivi et si je me rapelle bien). Ce qui est illégal c'est la mise en circulation de ses copies (ce que fait le P2P).
Donc emprunter (chez un loueur de cassettes / DVD ou une médiathèque) pour copier est une activité légale. Je crois que les loueurs / prèteurs payent justement une redevance exprès pour ce type d'usage de leurs prets / locations.
Ce que je ne savais pas c'est que le pret du CD par un copain etait légal, vu que je croyais que le cercle famillial etait restreint strictement à la famille.
[^] # Re: Idée
Posté par Toufou (site web personnel) . En réponse au journal Télécharger pas illégal?. Évalué à 2.
Je peux tres bien détenir des fichiers que j'ai copié moi même depuis les CD / DVD que j'ai loué ou emprunté, et jusqu'à preuve du contraire ça relève aussi de la copie privée. Je n'utilise donc pas le net pour les télécharger et donc ne rentre pas dans le cadre de la redevance... Comment faire le distingo ?
Quand à l'aspect gratuit / payant, c'est clair que ça pose des questions rigolotes : la MDK est payante mais libre donc librement téléchargeable => donne-t-on une part de la redevance a MDK ?
Les oeuvres completes de Neos (je ne sais même pas ce que c'est mais admettons que ce soit un groupe de zik) sont gratuites (téléchargeables gratuitement sur leur site) mais pas libres (tu n'as pas le droit de les distribuer par exemple) : donne-t-on des sous au groupe ?
Bon courage aux législateurs :)