Non. D'un point de vue libriste on s'en contre-fou. On veut un driver GPL.
Non, d'un point de vue libriste on veut un driver libre (éventuellement GPL mais BSD par exemple c'est bien aussi).
Mais d'un point de vue libriste, on peut aussi vouloir ou avoir besoin des fonction 3D de sa carte, donc en attendant le pilote libre, on peut utiliser le méchant pilote proprio. Tout les libristes ne le sont pas au même niveau.
Et attendre un driver libre? Tu n'as pas suivi les déclarations de nvidia sur le sujet: "pas de publication des spécifications de programmation hardware".
Les specs ne sont pas indispensable pour faire un pilote libre. Elle permettent de le développer beaucoup plus rapidement, simplement et efficacement, mais c'est possible sans, justement par reverse enginering.
Sinon on aurrait beaucoup moins de drivers dans Linux.
Hein? Tu le fais exprés? C'est le fait de faire un blob priorio dans Linux qui est un super générateur de haine. Manifestement tu crois que les devs là-bas sont suffisament niais pour ne pas avoir deviner que mettre un blob dans Linux allait générer un bon paquet de haine... c'est vrai que c'est à peine de la provocation... c'est une haine bien méritée hélas.
Bin ils nous détestent: quel crétin hier faire chier les libristes à mettre un blob dans Linux. Si ils veulent faire moins cher, ils n'ont qu'a arrêter leur driver, par contre ça fera chier nettement moins de libristes, ce qui dommage pour eux. Il n'y pas mieux que le blob pour faire chier.
Tout d'abort : il n'ont pas mis un blob dans le noyau ; ils proposent un pilot propriétaire que tu peut "de manière volontaire" télécharger et installer sur ton ordi.
C'est un acte purement volontaire, et c'est un choix que font ce qui l'installe. À ce niveau, d'un point de vue libriste pur, les pilotes libres mais qui utilisent un firmware proprio et qui sont inclus dans le noyau sont pire.
Ensuite, libre à toi de penser que chez NVidia, ils claque leur thune pour évelopper un pilote pour Linux, dans le but de faire chier les développeurs.
Personellement, je reste persuadé qu'ils le font parce que pour eux ça vaut le coup d'être présent sur cette plateforme. Quoi qu'on dise, Linuw ce développe doucement, aussi bien chez le particulier qu'en entreprise ; et de plus en plus de gens sont demandeurs de bonne performances 3D. C'est un marché qui a de l'avenir et à mon avis NVidia investi dans Linux pour cette raison et pas "pour faire chier les devs".
C'est forcément une expérience personnelle, puisque la réalité globale, personne de la détient, toi inclu. Un vendu a nvidia peut facilement venir sur les forums et poster une expérience opposée. Après ça... on ne crois plus rien. Par contre il y a des gens que se connaissent plus et qui savent qu'un poste de telle personne vaut plus qu'un autre... mais là est un autre débat. Donc il s'agit de mon expérience personnelle.
C'est ce que j'appelle l'effet forum, on retrouve la même chose pour le matos Photo. J'avais fait un long post la dessus sur un forum photo justement. En résumé :
Il y a 20 ans, la communication sur les nouveaux objectifs se faisait uniquement par des magazines spécialisé et les boutiques. Quand un objectif était défectueu il était remplacer par le SAV et c'est tout.
Pour qu'un objectif ait la réputation il fallait qu'il soit rééllement mauvais ou qu'il soit sujet à un très grand nombre de retour.
Maintenant tout le monde donne son avis sur le net, et étant donné la nature humaine, les insatisfaits gueulent plus fort...
Donc, de nos jours, pour qu'un objectif ait une mauvaise réputation, il suffit que 2 ou 3 des premiers acheteur ait un objectif défectueux et en lisant les forums tu as l'impression que ces un problème général de cet objectif.
Mon experience personnelle avec NVidia : 3 ans à jouer, principalement à WoW sous Wine et quelques jeux un peu plus recent. En natif, surtout Quake 4.
Et moi je n'ai jamais eu de problèmes. Experience personelle aussi.
Pour ce qui est du compositing, je n'ai pas d'avis, je n'en ai jamais eu le besoin, donc jamais tester.
Parle avec des dévelopeurs libres sur le fait que nvidia ne release pas les spécifications de programmation hardware ET qui se permet un blob dans Linux... là tu vas voir ce qu'est la haine.
À ma connaissance, NVidia n'a en aucun cas l'obligation de donner ses specs et respecte la GPL avec leur pilote propriétaire.
Si je comprend bien, tu trouverai moins génant que NVidia ignore complètement Linux et ne donne ni specs, ni pilotes ?
De plus j'ai abandonné le gaming natif sur GNU/Linux car leur driver freezait bien trop souvent.
On va dire que ça dépend pour qui...
Je me suis remis à jouer il y a 3 ans sous Linux en installant pour l'occasion les drivers NVidia et globalement j'ai beaucoup moins de problème que les potes qui sont sous Windows. Et je ne suis pas le seul, c'est le cas de toutes mes amis qui jouent sous Linux avec une carte NVidia et le driver proprio.
Donc, par rapport a ce qu'on peut trouver chez la concurence ils sont loin d'être mauvais.
De plus si tu as un Linux qui casse une API interne (plutôt souvent) tu dois attendre qu'ils daignent mettre à jour leur driver et ils ne sont paaaaaaaaaaas pressés... parfois c'est des mois.
Là tu parle plus de politique : NVidia à fait le choix de pilote fermé. Ce choix entraine le fait qu'ils doivent metre eux-même le pilote à jour et donc entraine un retard par rapport au dernier noyau.
Maintenant est-ce que ça en fait un pilote de merde ? On peut critiquer ce choix, ce que je fais, mais d'un point de vue technique ça n'implique absolument pas que le pilote soit mauvais.
Il y a d'excelents logiciels proprio, et des logiciels libre de merde.
De manière pragmatique : la majorité des utilisateurs utilise le noyau fournis par la distrib, un noyau qui a générallement été tester pendant quelques temps, qui n'est pas le dernier noyau sortit la semaine dernière. Donc c'est quand même rare de ne pas avoir de pilote NVidia pour sont noyau standard.
Si tu veux être bleeding edge, tu assumes...
Bien sûr un mode de dévellopement ouvert serait bien mieux, bien sûr il y a des bugs, mais :
- si on compare à ce qui ce fait dans le monde propriétaire, les pilotes NVidia sont plutôt parmis les meileurs en stabilité ;
- si on compare à ce qui se fait en Open source, ils sont parmis les meilleurs en performance et fonctionalités.
Je ne dit pas que NVidia c'est génial, mais c'est mieux que beaucoup d'autre et la majorité des critiques sont en générale fausses.
Même si je n'approuve pas leur choix de licence, ça ne m'empêche pas de le respecter, et d'admettre que leur pilote sont loin d'être pourris.
Mais il semble que pour certains, logiciel propriétaire est forcément synonyme de grosse merde.
nvidia est là uniquement pour générer de la haine, manifestement c'est des gars bon à ça.
hum, hum, hum....
Va vraiment falloir que tu m'explique !
Je dois avouer que je vois pas vraiment ce qui a pûs te passer par la tête en écrivant ça.
Me dit pas que tu crois que NVidia dépense de l'argent pour faire des pilotes Linux uniquement pour que des geeks partent en trolls quand ils sortent une version le vendredi ?
NVidia fait des pilotes pour Linux par ce qu'ils estime que ce marché est intéressant pour eux.
L'offre Dell sous linux pour les particuliers est vraiment (mais VRAIMENT) limitée : le modèle de base (le plus pourri qu'ils aient) et le XPS.
C'est mieux que beaucoup de constructeurs qui ne proposent absolument rien.
Ça coute cher de mettre en vente une machine sous linux, encore plus dans le cas de configuration variables comme chez Dell. Donc, tant qu'ils n'en vendent pas assez, il ne vont pas étendre l'offre à toute la gamme.
De plus certains modèles sont en fin de vie, ce serait stupide de leur part de faire tous les tests pour vendre Linux dessus pendant quelques mois seulement.
10km à vélo pour aller au centre UPS...
Tu le dis : ce n'est pas la faute de Dell ; moi j'aurais même tendance à penser que c'est de ta faute. UPS livre à domicile, donc si tu es aller le chercher au centre c'est :
- soit tu n'as pas eu le courrage d'attendre que le livreur repasse le jour suivant et donc tu est aler le chercher directement chez eux ;
- soit tu nn'était jamais la quand il est passé et tu n'était pas là non-plus le jour du rendez-vous qu'ils ont pris, dans ce cas tu peut demander à ce qu'il soit conserver 3 jours et c'est toi qui va le chercher.
Bref un problème qui n'a rien à foutre ici...
"tout fonctionne avec GNU/Linux" n'est pas tout à fait vrai. "tout fonctionne avec Ubuntu" serait plus correct. Faudrait voir à pas trop confondre... En effet, des tas de périphériques de cette machine (Wifi, carte nvidia, etc) utilisent un chipset tout pourri, qui a besoin d'un firmware proprio. Sous pas mal de distribs (surtout les non clic-clic-clic) ça ne marche pas de base.
Dell te vend le portable avec Ubuntu et là ça marche. Si tu veux installer autre chose, c'est ton problème. Il y a tout ce qu'il faut pour que les distribs puisse fonctionner. Pour celles qui ne veulent pas distribuer le firmware, il y a à peu près toujours une solution pour l'installer manuellement et simplement.
Personnellement, ça ne me semble pas du tout abhérent que Dell te fournisse un seul système. Si tu veux en changer, à toi de faire un peut d'efforts.
Pour les distribs non-clic-clic-clic, en effet ça ne marche pas de base, comme à peu près tout le reste... Ce n'est pas à cause du portable Dell mais plutôt dû à la politique de la distrib.
J'ai pris la version sans NVidia, car je refuse de donner de l'argent à une suciété qui ne fournit que des drivers de merde et, qui plus est, proprios. Mais le chip Intel est nikel pour mon utilisation.
NVidia est quand même une des rare société qui fournisse de pilotes Linux pour son materiel. Et des pilotes qui, malgré tout ce que l'on peut lire, sont de qualitée très correcte par rapport aux standards des pilotes propriétaires.
Il y a encore pas si longtemps, NVidia était la seule solution pour avoir de la bonne 3D sous linux, et même si ça grognait sur le fait que les pilotes soient proprio, beaucoup félicitait quand même NV d'être la seule boite à tenir un peu compte de Linux.
Mais depuis qu'ATI/AMD à changer de politique, tout le monde semble avoir oublier que les pilote ATI était de belle merde à côter de ceux de NVidia.
Donc : OUI la politique de NVidia est loin d'être la bonne, et on préfererais des specs et des pilotes libre, mais NON leur drivers ne sont pas si merdique que ça et au moins ils tiennent compte de Linux, et on peut espérer qu'ils finissent par imiter ATI/AMD.
Bon pour finir, je sais, je suis un stroumpf grognon ! Il faut au moins louer l'initiative de Dell. Sans elle, j'étais bon pour le tribunal pour me faire rembourser un OS dont je ne veux même pas entendre parler (et depuis le Brésil, je te racontes même pas le bordel pour suivre l'affaire...). Mais bon, si on gueule pas, si on pousse pas un peu du pied, il va vite se passer la même chose que pour les netbooks ASUS : windows only. Il FAUT faire pression sur les assembleurs pour leur dire que OUI on veut du Libre (linux pourquoi pas) et OUI on veut qu'il marche, du coup, si ça marche pas, c'est à eux de faire pression sur les constructeurs...
Tu peut tout à fait grogner, c'est même très bon pour la santée... mais il faut grogner sur des choses qui le méritent et face à la bonne personne...
L'offre Linux de Dell est franchement pas mal comparée à celle de la concurence. (à part pour les tarifs...) Ils fournissent un système qui marche, si toi tu as eu un problème avec le tiens, c'est le genre de chose qui arrive aussi sous Windows et qu'ils gèrent relativement bien.
Faire pression sur les assembleur, au final ça va surtout donner des pilotes proprio. Si tu veux des specs ou des drivers libres, c'est plutôt directement sur les fabriquant de matos qu'ils faut pression.
Au moins, tu as déjà réussis à réalisé un challenge :
"Trouver un exemple clair de journal qui serait bien sur les forums, pour expliquer simplement au gens la différence entre les deux."
En postant dans les journaux, tout ce que tu risque c'est d'obtenir des commentaires inutile ou trollesque comme le miens. Pour des réponses constructives et un espoir pour ton problème, il suffit d'aller voir dans les forums.
Donc tout dépend du type de réponses que tu espère.
Le logiciel server : squeezecenter tourne sans problèmes sur ces modèles de NAS, c'est même officiellement suporté par le constructeurs.
Donc il suffit que les deux soient sur le reseau, pas besoin de l'ordi. Tu peut même brancher le NAS directement sur le transporter/squeezebox si tu n'as pas de reseau la ou tu es.
Tu prend un transpoteur ou une squeezebox chez slimdevices, tu rajoute un QNAP TS-209 / TS-109 et tu asa une solution qui marche très bien.
Et si tu veux la musique dans plusieurs pièces, tu met une box dans chaque et ça roule.
Pas besoin d'un PC allumé, ça marche très bien sans. Le PC te donne access à une interface plus poussée pour des besoin plus ponctuels.
Pour la télécommande, soit tu reste sur celle de base, qui marche très bien, ou tu passe au modèle controller avec un bel écran intégré.
En plus tu y gagne un NAS, donc un stockage réseau accessible par tous les ordis de la maison.
C'est ce que j'ai depuis longtemps, et franchement je ne passerais à une solution apple pour rien au monde, du moins tant qu'ils n'aurons pas changé de politique.
C'est sûr, il n'y a pas la vidéo, mais pour la video j'ai mon lecteur DVD qui remplit tout à fais son rôle. Pour la musique, ce genre de solution m'est indispensable rien que pour faire de playlistes ou ne pas changer en permanence mes CDs. Pour les DVDs le problème est différents, j'enchaine pas trois DVDs à suivre, et quand je regarde 1 DVD je peut me lever 3minutes le temps de le mettre dans le lecteur...
Oui et non, c'est toujours le probleme des 20% utilises, mais ces 20% ne sont pas les memes pour tout le monde.
Dans mon cas ce serait plutôt moins de 1%, et personnellement ça me gonfle d'attendre 15sec le lancement de tous les trucs dont je ne vais pas me servir, de voir plein de boutons qui masquent ceux qui me servent réellement. Donc Office n'est pas la meilleure suite bureautique dans tous les cas, un petit traitement de texte et petit tableur tout simple sont suffisant pour beaucoup de personnes.
Je ne critique pas le fais que Office soit la meilleur suite pour certains, je dis juste qu'il ne faut pas généraliser.
je pars pas d'un principe, je pars d'une realite: a l'epoque tout le monde avait Office et Windows, bref, l'interop n'etait pas un probleme pour les clients. C'etait surement un probleme pour les concurrents, mais pas pour les clients de MS.
Principe ou réalité, ici c'est la même chose. L'interopérabilité est un problème pour le client car il n'a pas le choix, il est obliger d'utiliser Office. Je te renvoi à l'entreprise dont je parlais, qui est un cas que je connais bien mais qui n'est pas isolé. Il y a d'autres outils bureautique qui leur conviendrais mieux : plus simple ou plus légère ou moins chères... Mais ils ne peuvent les utiliser car leurs clients leurs envoie des documents Office et veulent du Office en retour et seul la suite Microsoft sait lire correctement son format.
Parmi les client de Microsoft, la majorité n'on pas choisit Office car il pensent que c'est la meilleure suite pour ce qu'ils ont besoin de faire mais parce qu'ils n'on pas le choix. C'est donc bien un problème pour le client : il ne peut pas aller voir ailleur. Il ne peut pas prendre mieux ou moins bien, plus ou moins cher...
Pas besoin de standard, ca existait deja pour les .doc depuis des annees, MS le fournissait meme gratuitement.
Microsoft le fournis pour tous les systèmes ? Il y a besoin des standard justement pour que l'on ait complètement le choix. J'ai vu pas mal de postes de travails avec deux ordinateur : des personnes qui bosse sous un unix quelconques mais qui on quand même besoin d'un poste windows à côter mais qui sert à peu près que pour 1/2h de paperasse à lire ou écrire par jour. Et là encore pas le choix...
Le format .doc est documente en libre acces depuis 2006, simplement qu'il y a autre chose que la doc qui empeche un rendu fidele. Notamment le fait que le soft doit etre a peu pres construit autour du format, ca se voit avec OO et ODF et Office et .doc.
Là on rentre dans des aspect que je ne maîtrise pas, je n'ai pas lu les standards et je n'ai jamais programmer de suite bureautique.
Mais j'ai quand même pas mal programmer et je doute qu'il soit impossible de faire un format ou les bases de la mise en page soit facilement implémentable par tous de manière rigoureuse et assurant quasiment le même rendu partout.
Le problème c'est que les formats proposés aujourd'huis sont issus de grosse suites bureautique qui on un lourd passé à trainer et que ça se sent de ce que j'ai pus comprendre.
Je ne jette la pièrre à personne, mais à mon avis on n'en serait pas là si dès le début (c'est-à-dire il y a un paquet d'années...) les différents acteurs c'était mis d'accord au moins sur une base comune et l'avais standardisé. Je comprend que chacun veuille ajouter ses fonctionalitées révolutionnaire, mais il y aurait eu un minimum de fais à l'époque....
Certainement, mais dans ce cas il n'y a pas grand monde qui fait mieux, alors on peut dire que toutes les grosses boites sont des enfoires, mais ca n'avance personne.
Mais même si tout le monde le fais, ce n'est pas pour cela que c'est bien....
Les editeurs supportent les plateformes en fonction du cout et des benefices. La fragmentation entre distribs, les changements frequents et le manque de doc avec exemples n'aide certainement pas Linux de ce cote la.
Ça n'a pourtant pas l'air de poser de problèmes à BibbleLabs par exemple. Avec la LSB il y a quand même moins de problème de compatibilitée entre les distrib, Si tu fournis un deb ou un rpm, il y a généralement des comunautés dèrrière qui se chargent de faire le reste pour les autres distribs.
Pour ce qui est du manque de doc... J'ai tendance à m'occuper que des partie algo de brute... donc pour moi en général le pire qu'il me faut c'est ma doc posix...
Juste pour mon info personnelle, qu'est-ce qu'il manque comme doc qui serve rééllement à pas mal d'applications ? Avec la doc posix + celle de l'interface graphique (QT est très bien documenté, GTK au dernière nouvelle un peu moins) tu fais déjà ce que font la majoritée des applis.
Le journal décrit comment arnaquer les impots, ça n'a rien à voir avec du blanchiment d'argent.
C'est bien du blanchiment et pas de l'arnaque au fisc. La déduction d'impots est prafaitement légale.
Par contre, il y a bien blanchiment car au lieu de payer les impots avec de l'argent propre, tu le paye en déductions fiscales que tu obtiens avec de l'argent sale.
Tu as donc bien blanchi de l'argent car au début tu as de l'argent sale, et a la fin tu as de l'argent propre (celui que tu n'as pas donner aux impots grace à la déduction)
Et il ne décrit que la moitié du truc, il ne dit pas comment l'asso justifie l'argent qui repart dans l'autre sens.
Il donne pourtant quelques exemples : cheques, notes de frais, poste de permanent pour la fille d'intel
Et ça ne concerne que 25% du don ; les autres 75% ne sortent pas des finances de l'asso, ce sont des déductions fiscales. Donc c'est de l'argent que l'entreprise ne va pas dépenser.
Globalement, j'ai trouvé tes interventions plutôt pertinentes dans ce "troll" mais là, quand même il y a des choses qui méritent une réaction...
Et ? Oui MS n'a pas ete le pionnier la dessus. En retour, ils ont fourni et continuent de fournir de loin la meilleure suite bureautique du marche, OO n'est pas grand-chose d'autre qu'une pale copie d'Office.
En effet MS à été pionnier dans ce domaine et OOo ne fais globalement que copier, par contre "meilleure suite bureautique" ? Il faut bien préciser dans quel domaine.
AbiWord ou Wordperfect (d'après mes souvenirs) sont, par exemple, bien supérieur pour un utilisateur qui ne fait que taper une lettre de motivation ou un CV une fois par an.
Office est, actuellement, la meilleur suite dans le cas d'un utilisateur relativement avancé et qui a besoin de fonctions dont j'ignore même l'existence. Mais il met du temps à ce lancer, consomme beaucoup de ressource et propose une foultitude de commandes inutile pour une utilisation de base.
Les standards c'est sympa pour les gens qui ne veulent pas Office, mais ceux-la, c'est pas les clients de MS. [...] Arf, quel rapport avec les clients ? Les specs ca aide les concurrents, les clients ils etaient tous sous Office, echanger les documents etait donc plus que simple [...]Incompatibilites ? Lesquelles ? L'utilisateur de base il a zero probleme pour communiquer et echanger, tout le monde a Windows...
Tu part du principe que tout le monde à Windows et Office, donc tout le monde utilise le format "doc", donc il n'y a pas besoin de standard.
Mais le problème est à prendre dans l'autre sens : Il n'y a pas de standard, donc tout le monde fait sa tambouille. Hors Microsoft domine le marché, donc sont format domine le marché.
Avec un format fermé sans documentation qui est utilisé quasi-exclusivement par tout le monde, il est très difficile pour une nouvelle suite bureautique de se faire une place, aussi bonne soit-elle.
Cette suite pourrait proposer toutes les fonctions de Office plus d'autres très intéressantes, le tout avec une consommation de ressources minimum, une interface super bien foutue et une compatibilité avec tous les systèmes. Si elle ne permet pas de lire le format "doc" elle ne sera pas utilisée, tout simplement parce que les utilisateurs disposent d'une très grande quantité de document existant qu'ils ont besoin de pouvoir relier et modifier, et parce que le format d'échange actuel est le format doc.
Tu dis que le client c'en fou des standards, mais ces faux. Indirectement il est concerné et ces d'une grande importance pour lui. Actuellement il n'a pas le choix, il est obliger d'utiliser Office et donc Windows pour pouvoir communiquer, tout simplement parce que le marché est fermé à cause du format "doc".
Bien sûr, le format "doc" a été étudié et en grande partie documenté, mais il suffit de voir ce que donne l'ouverture de beaucoup de fichier Office dans les différentes suites pour voir que ça reste pas franchement génial. Avec un vrai standard ouvert, il serait bien mieux supporté dans les différentes solutions alternative et le client aurait le choix.
Avec un vrai standard il serait par exemple possible de faire un outils léger qui ne fait qu'afficher les documents. Personnellement ça me suffirait, ça me permettrait de voir correctement les documents que l'on m'envoie, plutôt que de me taper les bouses que m'affiche AbiWord dès que le document utilise autre chose que du gras ou de l'italique.
Et pour mon usage d'édition je me contenterait de AbiWord pour les trucs simple et LaTeX pour les trucs plus complexes. Des outils qui sont adaptés à mon utilisations et que j'ai choisis.
Les standards permettent à l'utilisateur de choisir, là ou les formats fermés dominant le marché ne permettent que d'imposer le choix à l'utilisateur.
Et je peut assurer que je connais plusieurs entreprises ou aussi bien Windows que Office ne sont pas installés par choix, mais par obligation. J'ai discuter avec le patron d'une d'entre elles à ce sujet il y a de ça un petit moment, Il utilise OOo à titre personnel et le trouve suffisant pour son usage et estime qu'il remplacerait très bien Office dans sa boite. Les problèmes :
- ses clients envoie et veulent recevoir du "doc" car eux non-plus n'ont pas le choix, et le support du "doc" est trop imprévisible dans OOo ;
- il a une plein d'archives au format "doc" et même si globalement il pourrait embaucher quelqu'un le temps de tout convertir, en pdf par exemple, les autres problèmes font qu'il ne peut pas encore migrer et donc il ne peut pas se permettre cette dépense pour le moment ;
- tout son personnel est formé à Office car toutes les formation se font sous Office pluisque le marché est fermé, il n'y a pas encore de vrai système de formation pour OOo car les gens sont bloqués sous Office.
Pour ce qui est de virer Windows, il n'a pas vraiment d'avis car il ne connaît pas ce qui existe comme autres solutions. La encore, parce que le marcher est fermé.
Bref, tous ses problème pour migrer vers autre chose sont lié au format utilisé par Office qui empêche toutes conccurence de s'installer.
Pour conclure
Office à actuellemnt une position dominante et ne peut être détronner grace à son format fermé. Un format standardisé et librement implémentable est important pour le client, car ça lui donne le choix.
Au final Office ces imposé peut-être car il était le meilleur (je n'en sais rien, je ne connait pas assez les autres logiciels d'avant qu'il prédomine, n'y les besoin de l'époque) mais, ensuite il a vérouillé le marché non-pas grâce à ses qualités mais grace à son format fermé.
De mon point de vue je me fou du format de fichier qui va gagner, à partir du moment ou il est standard et librement implémentable. Il y a actuellement deux formats standardisés à ma connaissance : OOXML et ODT. Je n'y connaît rien en format de fichiers mais de ce que j'ai entendu dire, les deux on des défauts, mais ce que j'éspère c'est qu'ils permettrons une vrai intéropérabilité entre les suites.
Si c'est le cas, je suis sûr que Office restera leader encore un moment dans toutes les situations ou il y a besoin de vrai fonctionalitées avancées, mais au moins ça va ouvrir la porte à une vrai concurrence et donner leur chance à tous les autres.
PS: Emmerder le monde ? Elle n'emmerde certainement pas plus le monde que bcp d'autres societes
Ce n'es pas parce que ton voisin fais pire que toi que ce que tu fais est bien...
Suffit de voir la masse disponible de softs sur les 2 plateformes, et quelle plateformes les editeurs supportent
Les éditeurs supportent les plateformes en fonction des clients envisagés plus qu'en fonction des contraintes de programmation.
Au dernières nouvelles apple remboursais sans problèmes MacOS sur demande.
Pour ce qui est des logiciels fournis avec les périphériques, c'est un autre problème par contre...
Mais obtenir une vrai victoire dans le cas de Windows permettra de généraliser facilement aux autres abus j'espère.
Je te rassure, j'avais compris l'aspect humoristique de ton commentaire... (et je l'ai même apprécié...)
Mais derrière l'humour se cachait une idée pas si conne que ça et c'est la dessus que portait mon commentaire, le tout dans l'idée de venir en aide à foulmetal canette.
Je ne suis pas sûr qu'il y ait besoin d'un support particulier dans le noyau pour ce genre de gadget.
Je dis peut-être une connerie, mais à mon avis, dès que tu branches une prise dans un port USB, l'alimentation se met en route sans intervention de l'OS.
Celui-ci est sûrement informé que tu as brancher un périphérique, et tente de détecter le type de périférique pour voir si il le supporte, mais même si ce n'est pas le cas, je ne pense pas qu'il coup l'alimentation.
Par exemple, aussi bien mon appareil photo que mon GPS ne sont pas supporter sous linux en USB, mais je peut quand même les brancher pour les recharger.
Pour résoudre le problème des mitaines, il faudrais plutôt chercher un moyen de couper l'alimentation d'un port USB dans les drivers USB par exemple. Il y a peut-être un moyen d'empêcher le comportement par default ?
Dans le cas de GREYCstoration, c'est parfaitement adapté car le temps de calcul est vraiment long par rapport au temps du transfert et du fork.
Pour G'MIC, à mon avis, c'est complètement différent car la majorité des fonctions qu'il propose sont très rapides sur les images gérées par Gimp. J'ai pas testé sur des images volumétrique par exemple, mais c'est un peu hors de propos pour Gimp.
Ce qui peut rendre les traitement long, c'est l'utilisation de longue macro qui demandent à G'MIC d'appliquer de nombreux éffets les uns à la suite des autres.
En poussant la philosophie des pipes à font, G'MIC aurrait été codé sous la forme de dizaines de tout petit programmes applicant un seul filtre, et on les enchainerais avec des pipes.
Tu aurrait par exemple un programme gmic_noise, un gmic_sqrt... Le problème c'est que toutes ces opérations sont très rapides et au final le coût d'un fork plus du transfert de données serait très largement superieur au coût du vrai traitement.
C'est, à mon avis, une des raisons qui fait que G'MIC est un programme unique. Il est capable de faire plein d'opérations rapides et de les enchainées tout seul sans pipe. Mais il peut aussi être piper avec d'autres programmes pour faire ce qu'il ne sait pas faire.
Les pipes sont un outils fantastique, mais pas pour tout.
Typiquement, lorsque un problème peut être diviser en plusieurs petites tâches à appliquer en séquence sur les données et que ces données sont traîtées en flux, c'est génial.
En plus, vu la quantité de tels outils déjà disponible, le plus souvent ça économise un max de temps, et sur une machine multi-processeur ça te donne un parallélisme gratuit. Les pipes ont beaucoup d'avantage pour traîter ce genre de données.
Mais dans le cas ou tu travaille sur toutes les données d'un coup, donc en gros : tout charger en mémoire, faire le calcul et sortir tout le résultat d'un coup, c'est déjà moins intéressant. Chacun de tes programmes doit attendre que le précédent ait finit tout son travail et écrit son résultat avant de pouvoir commencer à son tour à tout charger en mémoire et faire son propre boulot.
Dans ce cas les pipes ne servent qu'a éviter les fichiers temporaires.
Il reste l'avantage d'avoir des plus petits programmes réutilisable, mais un plus gros programme avec des options pour choisir la tâche à éffectuer sera plus intéressant car il permet de factoriser le code. De plus si tu peut lui d'appliquer plusieurs opération en séquence, il n'a pas besoin de recharger les données à chaque fois.
C'est le principe justement de G'MIC : Il n'y a pas un programme séparé pour chaque traitement et une utilisation avec des pipes. Il y a un gros programme et on lui donne la séquence d'opérations à appliquer.
Imagine le temps que mettrait certains des scripts fournis si il fallait transférer l'image entre chacun des traitements... Pour une photo en haute résolution avec les cannaux codés sur 16bits, ça fait un sacré ralentissement.
Pour l'intégration dans Gimp, il y a en gros deux possibilitées :
- Soit on intègre G'MIC c'est-à-dire que l'on automatise la séquence : sauvegarder, lancer G'MIC manuellement, charger ;
- Soit on intègre les fonctions de G'MIC et donc chaque fonction de G'MIC devient une fonction de Gimp.
Il me semble assez évident que, d'un point de vue utilisateur, la deuxième solution est plus puissante. Elle permet de mélanger les différentes fonctions sans se poser de questions. Mais elle est bien plus complèxes à implémenter et maintenir.
La première, par contre, à l'avantage d'être relativement simple à coder et maintenir. Bien sûr, on peut effectuer plein de petits appels et obtenir la même souplesse que dans le deuxième cas, mais c'est au prix d'un aller-retour de l'image à chaque appel.
Dans le cas ou l'on demande à G'MIC d'effectuer toute une série d'opérations, le temps de transfert est négligeable. Mais si l'on souhaite faire d'autre traitements avec Gimp, entre chaque fonction de G'MIC, ce temps de transfert est surement bien plus important.
(en passant, si GREYCstoration est lent sur des grosses images, c'est uniquement du à la complexité "théorique" de l'algorithme. Je crois pas que le code puisse être remis en cause de quelque manière que ce soit. Je te propose de reprogrammer le même algo, dans le même langage (C++) , je doute très fort que tu obtiennes un gain de performance significatif, aussi 'bon' programmeur que tu soit... )
Je ne prétend pas être un un bon programmeur, loin de là... J'avais jetter un coup d'oeil aux papiers que tu as publier sur le sujet, et.... ce sera pour plus tard...
Ma remarque sur la lenteur de GreycStoration n'était pas une critique, mais une constatation. D'un point de vue objectif, actuellement, vu les photos pour lesquelles j'en aurais besoin, je ne peut pas me permettre d'utiliser GreycStoration systématiquement.
Et je le regrette, même si ce n'est pas de ta faute, mais du à l'algo lui-même. De la même manière que je regrette qu'il pleuve les jours où je veut tondre la pelouse : on ne peut rien y faire, mais ça nous embette quand même ;-)
GreycStoration m'a permis quand même de récupérer des photos très bruitées ou NoiseNinja n'était pas suffisant, la seule chose c'est qu'il faut avoir un peu de temps devant soit et jouer avec les paramètres.
Après il faudrais peut-être que je change mon matos, mais j'ai pas trop les moyens pour le moment ;-)
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
J'aime la philosophie des outils unix, et les utilisent beaucoup. Il y a quand même une différence, c'est qu'ils sont prévus pour être utilisés en flux, alors que dans ce cas ce sont des échanges.
Si l'on souhaite écrire un script pour gimp qui alterne les traitement classique de Gimp et ceux de G'MIC, il va y avoir de nombreux allez-retours entre les deux.
Mais dans tous les cas, c'est principalement une affaire de goûts. Je ne fait que donner mon point de vue.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
Je ne te demande pas de le faire ;-) Je ne faisait que décrire mon rêve en tant qu'utilisateur. Dans tous les cas, je crois même que je préfère que tu continue de le faire comme maintenant, au moins je suis à peu près sûr qu'il va continuer à évoluer, pour mon plus grand plaisir.
Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
J'en suis beaucoup moins sûr que toi. Le passage à GEGL va permettre le traitement des photos 16bits dans Gimp (12bits dans mon cas) et donc sa prinipale limitation actuelle dans le dévellopement des fichiers RAW va être supprimée. Gimp 3.0 sera donc un très bon outils je pense pour ce genre de boulot, et au moins pour moi un plugins GreycStoration sera presque indispensable.
Écrire un node pour GEGL qui se contente d'appeler un programme externe est relativement simple, de même que la gestion des paramètres.
Donc, si personne ne le fais avant, il y a de fortes chance pour que moi je le fasse quand un Gimp basé sur Gegl sera utilisable. (pas la 2.6 qui, même si elle utilise Gegl, ne permet de manipuler les nodes dans l'interface)
Aie, maudite relecture... le bon terme est "craquer", de la même manière que l'on peut "craquer our un fille"... On va dire que ça fait partie du langage familier et que en effet j'aurais dûs utiliser un autre terme, mais bon, on est sur linuxfr... on va juste dire que c'était un jeu de mots...
Et, non, je n'ai pas "cracker" ce logiciel. J'ai payer la licence.
Le terme "efficace" n'était peut-être pas le plus adapté en effet, je pensais surtout en terme de "propreté".
Je ne critique absolument pas ce que tu fais. Bien au contraire... J'utilise G'MIC justement pour du traitement d'image : c'est simple, efficace et léger. J'adore GreycStoration, même si je l'utilise moins depuis que j'ai cracker pour une licence noise ninja. (petite parenthèses d'ailleurs, j'ai cracker pour NN par ce que GreyStoration à pour moi deux inconvénients, le reglage des paramètres est assez obscure, et il est parfois relativement lent... et quand j'ai 200 photos d'un spectacle à développer je manque de temps pour les réglages.)
Donc je disais que je ne critique pas ton travail, c'est juste que je suis un peu maniaque quand on parle de code... et oui, désolé, on ne se refait pas. Et en plus je préfère que ce soit les autres qui changent leurs méthodes que moi ;-)
Gimp 2.4 c'est déjà un truc gros et lourd, il est dur de rentrer dedans et l'interface pour les scripts est à mon avis mal faite. Donc pour cette version à mon avis ta solution est la meilleure.
Pour les futures versions 3.0 et plus, il y aurra par contre un coeur bien plus propre et simple : GEGL, et rendre disponibles les fonction de G'MIC sous forme de node GEGL permettrait de tout utiliser de manière uniforme. L'API est simple et il y a plein de manière de l'exposé pour fire des scripts. Que ce soit un binding direct et donc des script complexes mais puissants, ou juste sous la forme du séquence de noeuds à créer et appliquer, ce qui reviens exactement au même que tes macro sous forme de paramètres.
Cela permet en plus de faire de simples nodes qui appelle G'MIC comme un programme externe et donc d'avoir un truc utilisable rapidement. Et si il y a un motivé aussi maniaque du code que moi, de porter les fonctions de G'MIC directement dans GEGL sans passer par l'appli externe. Les choses pouvant se faire progressivement.
La partie mise à jour automatique est, je pense complètement indépendante et devrais être dispo aussi bien pour les scripts G'MIC que pour les ScriptFu et autres, ça pourrait être fait avec avec un système tels que les dépots de packets des distrib, et un update automatique avec un cron.
Eh oui, merci pour cette nouvelle version d'un outils qui me rend bien service.
Bon boulot, même si comme toujours je suis pas un grand fan de tes convention de codage et que je reste simple utilisateur. Chacun ses goûts et je préfère que tu continu de maintenir et faire évoluer G'MIC et CImg.
Par contre pour ce qui est du Plug-in pour Gimp, l'idée me semble loin d'être si pertinente que ça. Gimp dispose déjà de toute une mécanique interne de traitement d'image. Toutes ces fonctions sont disponible pour l'écriture de script en Scheme, Python et il me semble avoir vu au moins un début de Lua. Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Bien sûr, il ne dispose pas de certaines fonction géniales de CImg et G'MIC, mais à mon avis ils serait bien plus intéressant de porter ces fonction dans Gimp et donc de bénéficier aussi de tous ce dont dispose Gimp.
Surtout avec la migration GEGL qui offre à ce niveau une souplesse de traitement géniale. Un portage des fonction de G'MIC sous la forme de node GEGL serait mon rêve...
Ça permetrait en plus de profiter des buffers et de la gestion colorimetrique de GEGL, de toutes ses fonctions bas niveau et de toutes la puissance de G'MIC.
Après je comprend que c'est difficile, étant donné les différence d'architecture interne c'est plus une réécriture qu'un portage, mais j'ai le droit de rêver...
D'un point de vue plus terre à terre, à mon avis une meilleure solution qu'un plugins resterait quand même des nodes pour GEGL qui appellent les différentes fonctions de G'MIC pour les cas ou l'on en utilise qu'une à la fois, et un node à qui l'on donne une macro G'MIC pour les cas ou l'on fait une petite chaine de traitement. (afin d'éviter les milliers de transfert...)
Au final ça permetrait d'utiliser toutes les fonction de G'MIC dans GEGL, dans le future Gimp et donc dans ses cripts et plugins, ainsi que dans tout autre outils qui utilisera GEGL. (et ça me simplifiera la vie un max....)
Promis, quand j'aurrais finit ma rédaction de thèse et que j'aurais un peu plus de temps je regarde ça sérieusement.
Ce n'est pas la FSF qui attaque free mais, Harald Welte (auteur d'Iptables), Erik Andersen et Rob Landley (auteurs de BusyBox).
Sûrement soutenus par la FSF bien sûr, mais c'est beaucoup plus clair quand on dit qui attaque réellement.
Au moins on sait à qui va aller le fric si ils gagnent le procès.
Quand à savoir qui à raison... Pour moi, l'interprétation de Free n'est pas celle de ceux qui on rédigé la GPL, mais la GPL ne définit pas clairement la diffusion. Ce sera donc à la loi de trancher. On verra bien ce que ça donnera.
Par contre, il me semblait qu'en France les contrats et donc les licences devait être rédigés en français pour être valable. Ce qui veut dire, soit que je me trompe, soit qu'il n'y a pas de contrat entre Free et les développeurs et que donc Free n'a pas le droit d'utiliser le code.
Quelqu'un peut-il m'éclairer la dessus ?
J'ai même tendance à penser que « Plus c’est simple à compliqué, Plus c’est vulnérable »
Tout simplement parce que quelque chose de compliquer à maintenir ou à utiliser ne sera tout simplement pas maintenu ou utilisé sur le moyen ou long terme.
Pour moi il y a plus de sécurité dans une solution, certes techniquement un peu moins bonne mais utilisée, qu'une solution parfaite qui ne l'est pas.
J'ai bossé sur un cluster bien plus petit que ceux-la (à côter on dirais un MO5...) mais j'en aurais eu 200 mis en drille queça n'aurait pasété plus rapide...
Il y a de gros problèmes de latence et de partage de données.Ily a grossièrement trois marches sur l'échelle :
1/ Les multi-processeurs:la latence en très faible et les resources peuvent être plus ou moins partagées ;
2/ Les clusters ou la latence est "raisonable" et la bande passante est suffisament importante pour permettre de gros échanges de données ;
2/ Les grilles ou la latence est abominable et ou il est difficile d'envisager de gros échange de données.
Sachant que pour la même puissance de calcul brute le 1/ est beaucoup plus cher que le 2/ qui est lui même beaucoup plus cher que le 3/. Mais pour la complexité de codage c'est souvent l'inverse...
Il faut prendre ce qui est le plus adapté à une tâche donnée. Dans mon cas les volumes était énormes mais un cluster était déjà disponible, donc on allait pas (et on ne pouvait pas...) racheter un multi-processeur de puissance équivalente.
Et il y a aussi le problème que ces technologies ont des limites. On ne peut pas faire un multiprocesseur aussi puissant que les meilleurs cluster ou un cluster aussi performant que les meilleures grilles.
Et à mon avis, l'idéal est une grille de bon clusters. Ce genre de trucs est en général utilisés par plein de monde avec des besoins différent, donc quand une personne à un algo qui s'adapte à la grille, il utilise un max de puissance, quand ce sont des tâche qui sont plutôt orientées clusters, on en fait tourner une sur chaque clusters. Ça permet d'utiliser au mieu les ressources sans que ça coute trop cher. (enfin, tout est relatif....)
[^] # Re: Modération
Posté par beagf (site web personnel) . En réponse à la dépêche Point de vue sur le Dell XPS M1330 fourni avec GNU/Linux. Évalué à 5.
Non, d'un point de vue libriste on veut un driver libre (éventuellement GPL mais BSD par exemple c'est bien aussi).
Mais d'un point de vue libriste, on peut aussi vouloir ou avoir besoin des fonction 3D de sa carte, donc en attendant le pilote libre, on peut utiliser le méchant pilote proprio. Tout les libristes ne le sont pas au même niveau.
Et attendre un driver libre? Tu n'as pas suivi les déclarations de nvidia sur le sujet: "pas de publication des spécifications de programmation hardware".
Les specs ne sont pas indispensable pour faire un pilote libre. Elle permettent de le développer beaucoup plus rapidement, simplement et efficacement, mais c'est possible sans, justement par reverse enginering.
Sinon on aurrait beaucoup moins de drivers dans Linux.
Hein? Tu le fais exprés? C'est le fait de faire un blob priorio dans Linux qui est un super générateur de haine. Manifestement tu crois que les devs là-bas sont suffisament niais pour ne pas avoir deviner que mettre un blob dans Linux allait générer un bon paquet de haine... c'est vrai que c'est à peine de la provocation... c'est une haine bien méritée hélas.
Bin ils nous détestent: quel crétin hier faire chier les libristes à mettre un blob dans Linux. Si ils veulent faire moins cher, ils n'ont qu'a arrêter leur driver, par contre ça fera chier nettement moins de libristes, ce qui dommage pour eux. Il n'y pas mieux que le blob pour faire chier.
Tout d'abort : il n'ont pas mis un blob dans le noyau ; ils proposent un pilot propriétaire que tu peut "de manière volontaire" télécharger et installer sur ton ordi.
C'est un acte purement volontaire, et c'est un choix que font ce qui l'installe. À ce niveau, d'un point de vue libriste pur, les pilotes libres mais qui utilisent un firmware proprio et qui sont inclus dans le noyau sont pire.
Ensuite, libre à toi de penser que chez NVidia, ils claque leur thune pour évelopper un pilote pour Linux, dans le but de faire chier les développeurs.
Personellement, je reste persuadé qu'ils le font parce que pour eux ça vaut le coup d'être présent sur cette plateforme. Quoi qu'on dise, Linuw ce développe doucement, aussi bien chez le particulier qu'en entreprise ; et de plus en plus de gens sont demandeurs de bonne performances 3D. C'est un marché qui a de l'avenir et à mon avis NVidia investi dans Linux pour cette raison et pas "pour faire chier les devs".
[^] # Re: Modération
Posté par beagf (site web personnel) . En réponse à la dépêche Point de vue sur le Dell XPS M1330 fourni avec GNU/Linux. Évalué à 2.
Il y a aussi l'avantage de disposer d'un pilote qui marche en attendant que le pilote libre soit disponible.
C'est de la haine pure en boite pour les développeurs du libre et beaucoup de personnes impliquées dans l'esprit du logiciel libre.
merci nvidia!
T'es pas sérieux là ? Tu crois vraiment que NVidia développe un pilote sous Linux par haine envers les développeurs du libre ?
Si NVidia nous détestait autant que ça, ils aurraient surement trouvé un moyen de faire bien plus chier pour moins cher.
[^] # Re: Modération
Posté par beagf (site web personnel) . En réponse à la dépêche Point de vue sur le Dell XPS M1330 fourni avec GNU/Linux. Évalué à 2.
C'est ce que j'appelle l'effet forum, on retrouve la même chose pour le matos Photo. J'avais fait un long post la dessus sur un forum photo justement. En résumé :
Il y a 20 ans, la communication sur les nouveaux objectifs se faisait uniquement par des magazines spécialisé et les boutiques. Quand un objectif était défectueu il était remplacer par le SAV et c'est tout.
Pour qu'un objectif ait la réputation il fallait qu'il soit rééllement mauvais ou qu'il soit sujet à un très grand nombre de retour.
Maintenant tout le monde donne son avis sur le net, et étant donné la nature humaine, les insatisfaits gueulent plus fort...
Donc, de nos jours, pour qu'un objectif ait une mauvaise réputation, il suffit que 2 ou 3 des premiers acheteur ait un objectif défectueux et en lisant les forums tu as l'impression que ces un problème général de cet objectif.
Mon experience personnelle avec NVidia : 3 ans à jouer, principalement à WoW sous Wine et quelques jeux un peu plus recent. En natif, surtout Quake 4.
Et moi je n'ai jamais eu de problèmes. Experience personelle aussi.
Pour ce qui est du compositing, je n'ai pas d'avis, je n'en ai jamais eu le besoin, donc jamais tester.
Parle avec des dévelopeurs libres sur le fait que nvidia ne release pas les spécifications de programmation hardware ET qui se permet un blob dans Linux... là tu vas voir ce qu'est la haine.
À ma connaissance, NVidia n'a en aucun cas l'obligation de donner ses specs et respecte la GPL avec leur pilote propriétaire.
Si je comprend bien, tu trouverai moins génant que NVidia ignore complètement Linux et ne donne ni specs, ni pilotes ?
[^] # Re: Modération
Posté par beagf (site web personnel) . En réponse à la dépêche Point de vue sur le Dell XPS M1330 fourni avec GNU/Linux. Évalué à 6.
On va dire que ça dépend pour qui...
Je me suis remis à jouer il y a 3 ans sous Linux en installant pour l'occasion les drivers NVidia et globalement j'ai beaucoup moins de problème que les potes qui sont sous Windows. Et je ne suis pas le seul, c'est le cas de toutes mes amis qui jouent sous Linux avec une carte NVidia et le driver proprio.
Donc, par rapport a ce qu'on peut trouver chez la concurence ils sont loin d'être mauvais.
De plus si tu as un Linux qui casse une API interne (plutôt souvent) tu dois attendre qu'ils daignent mettre à jour leur driver et ils ne sont paaaaaaaaaaas pressés... parfois c'est des mois.
Là tu parle plus de politique : NVidia à fait le choix de pilote fermé. Ce choix entraine le fait qu'ils doivent metre eux-même le pilote à jour et donc entraine un retard par rapport au dernier noyau.
Maintenant est-ce que ça en fait un pilote de merde ? On peut critiquer ce choix, ce que je fais, mais d'un point de vue technique ça n'implique absolument pas que le pilote soit mauvais.
Il y a d'excelents logiciels proprio, et des logiciels libre de merde.
De manière pragmatique : la majorité des utilisateurs utilise le noyau fournis par la distrib, un noyau qui a générallement été tester pendant quelques temps, qui n'est pas le dernier noyau sortit la semaine dernière. Donc c'est quand même rare de ne pas avoir de pilote NVidia pour sont noyau standard.
Si tu veux être bleeding edge, tu assumes...
Bien sûr un mode de dévellopement ouvert serait bien mieux, bien sûr il y a des bugs, mais :
- si on compare à ce qui ce fait dans le monde propriétaire, les pilotes NVidia sont plutôt parmis les meileurs en stabilité ;
- si on compare à ce qui se fait en Open source, ils sont parmis les meilleurs en performance et fonctionalités.
Je ne dit pas que NVidia c'est génial, mais c'est mieux que beaucoup d'autre et la majorité des critiques sont en générale fausses.
Même si je n'approuve pas leur choix de licence, ça ne m'empêche pas de le respecter, et d'admettre que leur pilote sont loin d'être pourris.
Mais il semble que pour certains, logiciel propriétaire est forcément synonyme de grosse merde.
nvidia est là uniquement pour générer de la haine, manifestement c'est des gars bon à ça.
hum, hum, hum....
Va vraiment falloir que tu m'explique !
Je dois avouer que je vois pas vraiment ce qui a pûs te passer par la tête en écrivant ça.
Me dit pas que tu crois que NVidia dépense de l'argent pour faire des pilotes Linux uniquement pour que des geeks partent en trolls quand ils sortent une version le vendredi ?
NVidia fait des pilotes pour Linux par ce qu'ils estime que ce marché est intéressant pour eux.
[^] # Re: Modération
Posté par beagf (site web personnel) . En réponse à la dépêche Point de vue sur le Dell XPS M1330 fourni avec GNU/Linux. Évalué à 6.
L'offre Dell sous linux pour les particuliers est vraiment (mais VRAIMENT) limitée : le modèle de base (le plus pourri qu'ils aient) et le XPS.
C'est mieux que beaucoup de constructeurs qui ne proposent absolument rien.
Ça coute cher de mettre en vente une machine sous linux, encore plus dans le cas de configuration variables comme chez Dell. Donc, tant qu'ils n'en vendent pas assez, il ne vont pas étendre l'offre à toute la gamme.
De plus certains modèles sont en fin de vie, ce serait stupide de leur part de faire tous les tests pour vendre Linux dessus pendant quelques mois seulement.
10km à vélo pour aller au centre UPS...
Tu le dis : ce n'est pas la faute de Dell ; moi j'aurais même tendance à penser que c'est de ta faute. UPS livre à domicile, donc si tu es aller le chercher au centre c'est :
- soit tu n'as pas eu le courrage d'attendre que le livreur repasse le jour suivant et donc tu est aler le chercher directement chez eux ;
- soit tu nn'était jamais la quand il est passé et tu n'était pas là non-plus le jour du rendez-vous qu'ils ont pris, dans ce cas tu peut demander à ce qu'il soit conserver 3 jours et c'est toi qui va le chercher.
Bref un problème qui n'a rien à foutre ici...
"tout fonctionne avec GNU/Linux" n'est pas tout à fait vrai. "tout fonctionne avec Ubuntu" serait plus correct. Faudrait voir à pas trop confondre... En effet, des tas de périphériques de cette machine (Wifi, carte nvidia, etc) utilisent un chipset tout pourri, qui a besoin d'un firmware proprio. Sous pas mal de distribs (surtout les non clic-clic-clic) ça ne marche pas de base.
Dell te vend le portable avec Ubuntu et là ça marche. Si tu veux installer autre chose, c'est ton problème. Il y a tout ce qu'il faut pour que les distribs puisse fonctionner. Pour celles qui ne veulent pas distribuer le firmware, il y a à peu près toujours une solution pour l'installer manuellement et simplement.
Personnellement, ça ne me semble pas du tout abhérent que Dell te fournisse un seul système. Si tu veux en changer, à toi de faire un peut d'efforts.
Pour les distribs non-clic-clic-clic, en effet ça ne marche pas de base, comme à peu près tout le reste... Ce n'est pas à cause du portable Dell mais plutôt dû à la politique de la distrib.
J'ai pris la version sans NVidia, car je refuse de donner de l'argent à une suciété qui ne fournit que des drivers de merde et, qui plus est, proprios. Mais le chip Intel est nikel pour mon utilisation.
NVidia est quand même une des rare société qui fournisse de pilotes Linux pour son materiel. Et des pilotes qui, malgré tout ce que l'on peut lire, sont de qualitée très correcte par rapport aux standards des pilotes propriétaires.
Il y a encore pas si longtemps, NVidia était la seule solution pour avoir de la bonne 3D sous linux, et même si ça grognait sur le fait que les pilotes soient proprio, beaucoup félicitait quand même NV d'être la seule boite à tenir un peu compte de Linux.
Mais depuis qu'ATI/AMD à changer de politique, tout le monde semble avoir oublier que les pilote ATI était de belle merde à côter de ceux de NVidia.
Donc : OUI la politique de NVidia est loin d'être la bonne, et on préfererais des specs et des pilotes libre, mais NON leur drivers ne sont pas si merdique que ça et au moins ils tiennent compte de Linux, et on peut espérer qu'ils finissent par imiter ATI/AMD.
Bon pour finir, je sais, je suis un stroumpf grognon ! Il faut au moins louer l'initiative de Dell. Sans elle, j'étais bon pour le tribunal pour me faire rembourser un OS dont je ne veux même pas entendre parler (et depuis le Brésil, je te racontes même pas le bordel pour suivre l'affaire...). Mais bon, si on gueule pas, si on pousse pas un peu du pied, il va vite se passer la même chose que pour les netbooks ASUS : windows only. Il FAUT faire pression sur les assembleurs pour leur dire que OUI on veut du Libre (linux pourquoi pas) et OUI on veut qu'il marche, du coup, si ça marche pas, c'est à eux de faire pression sur les constructeurs...
Tu peut tout à fait grogner, c'est même très bon pour la santée... mais il faut grogner sur des choses qui le méritent et face à la bonne personne...
L'offre Linux de Dell est franchement pas mal comparée à celle de la concurence. (à part pour les tarifs...) Ils fournissent un système qui marche, si toi tu as eu un problème avec le tiens, c'est le genre de chose qui arrive aussi sous Windows et qu'ils gèrent relativement bien.
Faire pression sur les assembleur, au final ça va surtout donner des pilotes proprio. Si tu veux des specs ou des drivers libres, c'est plutôt directement sur les fabriquant de matos qu'ils faut pression.
Donc oui pour grogner, mais intélligement.
# En effet, la boulette....
Posté par beagf (site web personnel) . En réponse au journal La boulette. Évalué à 10.
"Trouver un exemple clair de journal qui serait bien sur les forums, pour expliquer simplement au gens la différence entre les deux."
En postant dans les journaux, tout ce que tu risque c'est d'obtenir des commentaires inutile ou trollesque comme le miens. Pour des réponses constructives et un espoir pour ton problème, il suffit d'aller voir dans les forums.
Donc tout dépend du type de réponses que tu espère.
[^] # Re: Front Row
Posté par beagf (site web personnel) . En réponse au journal A la recherche (désespérée) du lecteur audio de salon des années 2000.... Évalué à 2.
Pour le WiFi il faut rajouter une clé WiFi supportée par Linux sur un des ports USB du NAS.
Tu peut même faire mieux : relier le réseau filaire et le réseau WiFi car les boxs peuvent faire un pont entre les deux.
[^] # Re: Front Row
Posté par beagf (site web personnel) . En réponse au journal A la recherche (désespérée) du lecteur audio de salon des années 2000.... Évalué à 3.
Donc il suffit que les deux soient sur le reseau, pas besoin de l'ordi. Tu peut même brancher le NAS directement sur le transporter/squeezebox si tu n'as pas de reseau la ou tu es.
[^] # Re: Front Row
Posté par beagf (site web personnel) . En réponse au journal A la recherche (désespérée) du lecteur audio de salon des années 2000.... Évalué à 5.
Et si tu veux la musique dans plusieurs pièces, tu met une box dans chaque et ça roule.
Pas besoin d'un PC allumé, ça marche très bien sans. Le PC te donne access à une interface plus poussée pour des besoin plus ponctuels.
Pour la télécommande, soit tu reste sur celle de base, qui marche très bien, ou tu passe au modèle controller avec un bel écran intégré.
En plus tu y gagne un NAS, donc un stockage réseau accessible par tous les ordis de la maison.
C'est ce que j'ai depuis longtemps, et franchement je ne passerais à une solution apple pour rien au monde, du moins tant qu'ils n'aurons pas changé de politique.
C'est sûr, il n'y a pas la vidéo, mais pour la video j'ai mon lecteur DVD qui remplit tout à fais son rôle. Pour la musique, ce genre de solution m'est indispensable rien que pour faire de playlistes ou ne pas changer en permanence mes CDs. Pour les DVDs le problème est différents, j'enchaine pas trois DVDs à suivre, et quand je regarde 1 DVD je peut me lever 3minutes le temps de le mettre dans le lecteur...
[^] # Re: Oui bien sur
Posté par beagf (site web personnel) . En réponse à la dépêche En vrac : ODF by MS, Torcs, FireUnit, Facebook et le libre, Project:Possibility. Évalué à 5.
Dans mon cas ce serait plutôt moins de 1%, et personnellement ça me gonfle d'attendre 15sec le lancement de tous les trucs dont je ne vais pas me servir, de voir plein de boutons qui masquent ceux qui me servent réellement. Donc Office n'est pas la meilleure suite bureautique dans tous les cas, un petit traitement de texte et petit tableur tout simple sont suffisant pour beaucoup de personnes.
Je ne critique pas le fais que Office soit la meilleur suite pour certains, je dis juste qu'il ne faut pas généraliser.
je pars pas d'un principe, je pars d'une realite: a l'epoque tout le monde avait Office et Windows, bref, l'interop n'etait pas un probleme pour les clients. C'etait surement un probleme pour les concurrents, mais pas pour les clients de MS.
Principe ou réalité, ici c'est la même chose. L'interopérabilité est un problème pour le client car il n'a pas le choix, il est obliger d'utiliser Office. Je te renvoi à l'entreprise dont je parlais, qui est un cas que je connais bien mais qui n'est pas isolé. Il y a d'autres outils bureautique qui leur conviendrais mieux : plus simple ou plus légère ou moins chères... Mais ils ne peuvent les utiliser car leurs clients leurs envoie des documents Office et veulent du Office en retour et seul la suite Microsoft sait lire correctement son format.
Parmi les client de Microsoft, la majorité n'on pas choisit Office car il pensent que c'est la meilleure suite pour ce qu'ils ont besoin de faire mais parce qu'ils n'on pas le choix. C'est donc bien un problème pour le client : il ne peut pas aller voir ailleur. Il ne peut pas prendre mieux ou moins bien, plus ou moins cher...
Pas besoin de standard, ca existait deja pour les .doc depuis des annees, MS le fournissait meme gratuitement.
Microsoft le fournis pour tous les systèmes ? Il y a besoin des standard justement pour que l'on ait complètement le choix. J'ai vu pas mal de postes de travails avec deux ordinateur : des personnes qui bosse sous un unix quelconques mais qui on quand même besoin d'un poste windows à côter mais qui sert à peu près que pour 1/2h de paperasse à lire ou écrire par jour. Et là encore pas le choix...
Le format .doc est documente en libre acces depuis 2006, simplement qu'il y a autre chose que la doc qui empeche un rendu fidele. Notamment le fait que le soft doit etre a peu pres construit autour du format, ca se voit avec OO et ODF et Office et .doc.
Là on rentre dans des aspect que je ne maîtrise pas, je n'ai pas lu les standards et je n'ai jamais programmer de suite bureautique.
Mais j'ai quand même pas mal programmer et je doute qu'il soit impossible de faire un format ou les bases de la mise en page soit facilement implémentable par tous de manière rigoureuse et assurant quasiment le même rendu partout.
Le problème c'est que les formats proposés aujourd'huis sont issus de grosse suites bureautique qui on un lourd passé à trainer et que ça se sent de ce que j'ai pus comprendre.
Je ne jette la pièrre à personne, mais à mon avis on n'en serait pas là si dès le début (c'est-à-dire il y a un paquet d'années...) les différents acteurs c'était mis d'accord au moins sur une base comune et l'avais standardisé. Je comprend que chacun veuille ajouter ses fonctionalitées révolutionnaire, mais il y aurait eu un minimum de fais à l'époque....
Certainement, mais dans ce cas il n'y a pas grand monde qui fait mieux, alors on peut dire que toutes les grosses boites sont des enfoires, mais ca n'avance personne.
Mais même si tout le monde le fais, ce n'est pas pour cela que c'est bien....
Les editeurs supportent les plateformes en fonction du cout et des benefices. La fragmentation entre distribs, les changements frequents et le manque de doc avec exemples n'aide certainement pas Linux de ce cote la.
Ça n'a pourtant pas l'air de poser de problèmes à BibbleLabs par exemple. Avec la LSB il y a quand même moins de problème de compatibilitée entre les distrib, Si tu fournis un deb ou un rpm, il y a généralement des comunautés dèrrière qui se chargent de faire le reste pour les autres distribs.
Pour ce qui est du manque de doc... J'ai tendance à m'occuper que des partie algo de brute... donc pour moi en général le pire qu'il me faut c'est ma doc posix...
Juste pour mon info personnelle, qu'est-ce qu'il manque comme doc qui serve rééllement à pas mal d'applications ? Avec la doc posix + celle de l'interface graphique (QT est très bien documenté, GTK au dernière nouvelle un peu moins) tu fais déjà ce que font la majoritée des applis.
[^] # Re: blanchir
Posté par beagf (site web personnel) . En réponse au journal Comment blanchir de l'argent avec une associations d'utilité publique. Évalué à 1.
Le journal décrit comment arnaquer les impots, ça n'a rien à voir avec du blanchiment d'argent.
C'est bien du blanchiment et pas de l'arnaque au fisc. La déduction d'impots est prafaitement légale.
Par contre, il y a bien blanchiment car au lieu de payer les impots avec de l'argent propre, tu le paye en déductions fiscales que tu obtiens avec de l'argent sale.
Tu as donc bien blanchi de l'argent car au début tu as de l'argent sale, et a la fin tu as de l'argent propre (celui que tu n'as pas donner aux impots grace à la déduction)
Et il ne décrit que la moitié du truc, il ne dit pas comment l'asso justifie l'argent qui repart dans l'autre sens.
Il donne pourtant quelques exemples : cheques, notes de frais, poste de permanent pour la fille d'intel
Et ça ne concerne que 25% du don ; les autres 75% ne sortent pas des finances de l'asso, ce sont des déductions fiscales. Donc c'est de l'argent que l'entreprise ne va pas dépenser.
Donc, relis le journal...
[^] # Re: Oui bien sur
Posté par beagf (site web personnel) . En réponse à la dépêche En vrac : ODF by MS, Torcs, FireUnit, Facebook et le libre, Project:Possibility. Évalué à 9.
Et ? Oui MS n'a pas ete le pionnier la dessus. En retour, ils ont fourni et continuent de fournir de loin la meilleure suite bureautique du marche, OO n'est pas grand-chose d'autre qu'une pale copie d'Office.
En effet MS à été pionnier dans ce domaine et OOo ne fais globalement que copier, par contre "meilleure suite bureautique" ? Il faut bien préciser dans quel domaine.
AbiWord ou Wordperfect (d'après mes souvenirs) sont, par exemple, bien supérieur pour un utilisateur qui ne fait que taper une lettre de motivation ou un CV une fois par an.
Office est, actuellement, la meilleur suite dans le cas d'un utilisateur relativement avancé et qui a besoin de fonctions dont j'ignore même l'existence. Mais il met du temps à ce lancer, consomme beaucoup de ressource et propose une foultitude de commandes inutile pour une utilisation de base.
Les standards c'est sympa pour les gens qui ne veulent pas Office, mais ceux-la, c'est pas les clients de MS. [...] Arf, quel rapport avec les clients ? Les specs ca aide les concurrents, les clients ils etaient tous sous Office, echanger les documents etait donc plus que simple [...]Incompatibilites ? Lesquelles ? L'utilisateur de base il a zero probleme pour communiquer et echanger, tout le monde a Windows...
Tu part du principe que tout le monde à Windows et Office, donc tout le monde utilise le format "doc", donc il n'y a pas besoin de standard.
Mais le problème est à prendre dans l'autre sens : Il n'y a pas de standard, donc tout le monde fait sa tambouille. Hors Microsoft domine le marché, donc sont format domine le marché.
Avec un format fermé sans documentation qui est utilisé quasi-exclusivement par tout le monde, il est très difficile pour une nouvelle suite bureautique de se faire une place, aussi bonne soit-elle.
Cette suite pourrait proposer toutes les fonctions de Office plus d'autres très intéressantes, le tout avec une consommation de ressources minimum, une interface super bien foutue et une compatibilité avec tous les systèmes. Si elle ne permet pas de lire le format "doc" elle ne sera pas utilisée, tout simplement parce que les utilisateurs disposent d'une très grande quantité de document existant qu'ils ont besoin de pouvoir relier et modifier, et parce que le format d'échange actuel est le format doc.
Tu dis que le client c'en fou des standards, mais ces faux. Indirectement il est concerné et ces d'une grande importance pour lui. Actuellement il n'a pas le choix, il est obliger d'utiliser Office et donc Windows pour pouvoir communiquer, tout simplement parce que le marché est fermé à cause du format "doc".
Bien sûr, le format "doc" a été étudié et en grande partie documenté, mais il suffit de voir ce que donne l'ouverture de beaucoup de fichier Office dans les différentes suites pour voir que ça reste pas franchement génial. Avec un vrai standard ouvert, il serait bien mieux supporté dans les différentes solutions alternative et le client aurait le choix.
Avec un vrai standard il serait par exemple possible de faire un outils léger qui ne fait qu'afficher les documents. Personnellement ça me suffirait, ça me permettrait de voir correctement les documents que l'on m'envoie, plutôt que de me taper les bouses que m'affiche AbiWord dès que le document utilise autre chose que du gras ou de l'italique.
Et pour mon usage d'édition je me contenterait de AbiWord pour les trucs simple et LaTeX pour les trucs plus complexes. Des outils qui sont adaptés à mon utilisations et que j'ai choisis.
Les standards permettent à l'utilisateur de choisir, là ou les formats fermés dominant le marché ne permettent que d'imposer le choix à l'utilisateur.
Et je peut assurer que je connais plusieurs entreprises ou aussi bien Windows que Office ne sont pas installés par choix, mais par obligation. J'ai discuter avec le patron d'une d'entre elles à ce sujet il y a de ça un petit moment, Il utilise OOo à titre personnel et le trouve suffisant pour son usage et estime qu'il remplacerait très bien Office dans sa boite. Les problèmes :
- ses clients envoie et veulent recevoir du "doc" car eux non-plus n'ont pas le choix, et le support du "doc" est trop imprévisible dans OOo ;
- il a une plein d'archives au format "doc" et même si globalement il pourrait embaucher quelqu'un le temps de tout convertir, en pdf par exemple, les autres problèmes font qu'il ne peut pas encore migrer et donc il ne peut pas se permettre cette dépense pour le moment ;
- tout son personnel est formé à Office car toutes les formation se font sous Office pluisque le marché est fermé, il n'y a pas encore de vrai système de formation pour OOo car les gens sont bloqués sous Office.
Pour ce qui est de virer Windows, il n'a pas vraiment d'avis car il ne connaît pas ce qui existe comme autres solutions. La encore, parce que le marcher est fermé.
Bref, tous ses problème pour migrer vers autre chose sont lié au format utilisé par Office qui empêche toutes conccurence de s'installer.
Pour conclure
Office à actuellemnt une position dominante et ne peut être détronner grace à son format fermé. Un format standardisé et librement implémentable est important pour le client, car ça lui donne le choix.
Au final Office ces imposé peut-être car il était le meilleur (je n'en sais rien, je ne connait pas assez les autres logiciels d'avant qu'il prédomine, n'y les besoin de l'époque) mais, ensuite il a vérouillé le marché non-pas grâce à ses qualités mais grace à son format fermé.
De mon point de vue je me fou du format de fichier qui va gagner, à partir du moment ou il est standard et librement implémentable. Il y a actuellement deux formats standardisés à ma connaissance : OOXML et ODT. Je n'y connaît rien en format de fichiers mais de ce que j'ai entendu dire, les deux on des défauts, mais ce que j'éspère c'est qu'ils permettrons une vrai intéropérabilité entre les suites.
Si c'est le cas, je suis sûr que Office restera leader encore un moment dans toutes les situations ou il y a besoin de vrai fonctionalitées avancées, mais au moins ça va ouvrir la porte à une vrai concurrence et donner leur chance à tous les autres.
PS: Emmerder le monde ? Elle n'emmerde certainement pas plus le monde que bcp d'autres societes
Ce n'es pas parce que ton voisin fais pire que toi que ce que tu fais est bien...
Suffit de voir la masse disponible de softs sur les 2 plateformes, et quelle plateformes les editeurs supportent
Les éditeurs supportent les plateformes en fonction des clients envisagés plus qu'en fonction des contraintes de programmation.
[^] # Re: Pas seulement microsoft, pas seulement les OS !
Posté par beagf (site web personnel) . En réponse à la dépêche Vente liée : ordinateurs-logiciels : le père noël du gouvernement se fait attendre!. Évalué à 4.
Pour ce qui est des logiciels fournis avec les périphériques, c'est un autre problème par contre...
Mais obtenir une vrai victoire dans le cas de Windows permettra de généraliser facilement aux autres abus j'espère.
[^] # Re: Merci pour l’info
Posté par beagf (site web personnel) . En réponse au journal Petites options entre amis. Évalué à 4.
Mais derrière l'humour se cachait une idée pas si conne que ça et c'est la dessus que portait mon commentaire, le tout dans l'idée de venir en aide à foulmetal canette.
[^] # Re: Merci pour l’info
Posté par beagf (site web personnel) . En réponse au journal Petites options entre amis. Évalué à 3.
Je dis peut-être une connerie, mais à mon avis, dès que tu branches une prise dans un port USB, l'alimentation se met en route sans intervention de l'OS.
Celui-ci est sûrement informé que tu as brancher un périphérique, et tente de détecter le type de périférique pour voir si il le supporte, mais même si ce n'est pas le cas, je ne pense pas qu'il coup l'alimentation.
Par exemple, aussi bien mon appareil photo que mon GPS ne sont pas supporter sous linux en USB, mais je peut quand même les brancher pour les recharger.
Pour résoudre le problème des mitaines, il faudrais plutôt chercher un moyen de couper l'alimentation d'un port USB dans les drivers USB par exemple. Il y a peut-être un moyen d'empêcher le comportement par default ?
[^] # Re: Merci pour l’info
Posté par beagf (site web personnel) . En réponse au journal Petites options entre amis. Évalué à 5.
5 * * * * root /sbin/shutdown -r now
Et ça devrais te donner le même comportement qui Windows avec MSN et IE. Une preuve de plus que Windows est plus simple et intuitif.
[^] # Re: Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Pour G'MIC, à mon avis, c'est complètement différent car la majorité des fonctions qu'il propose sont très rapides sur les images gérées par Gimp. J'ai pas testé sur des images volumétrique par exemple, mais c'est un peu hors de propos pour Gimp.
Ce qui peut rendre les traitement long, c'est l'utilisation de longue macro qui demandent à G'MIC d'appliquer de nombreux éffets les uns à la suite des autres.
En poussant la philosophie des pipes à font, G'MIC aurrait été codé sous la forme de dizaines de tout petit programmes applicant un seul filtre, et on les enchainerais avec des pipes.
Tu aurrait par exemple un programme gmic_noise, un gmic_sqrt... Le problème c'est que toutes ces opérations sont très rapides et au final le coût d'un fork plus du transfert de données serait très largement superieur au coût du vrai traitement.
C'est, à mon avis, une des raisons qui fait que G'MIC est un programme unique. Il est capable de faire plein d'opérations rapides et de les enchainées tout seul sans pipe. Mais il peut aussi être piper avec d'autres programmes pour faire ce qu'il ne sait pas faire.
[^] # Re: Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Typiquement, lorsque un problème peut être diviser en plusieurs petites tâches à appliquer en séquence sur les données et que ces données sont traîtées en flux, c'est génial.
En plus, vu la quantité de tels outils déjà disponible, le plus souvent ça économise un max de temps, et sur une machine multi-processeur ça te donne un parallélisme gratuit. Les pipes ont beaucoup d'avantage pour traîter ce genre de données.
Mais dans le cas ou tu travaille sur toutes les données d'un coup, donc en gros : tout charger en mémoire, faire le calcul et sortir tout le résultat d'un coup, c'est déjà moins intéressant. Chacun de tes programmes doit attendre que le précédent ait finit tout son travail et écrit son résultat avant de pouvoir commencer à son tour à tout charger en mémoire et faire son propre boulot.
Dans ce cas les pipes ne servent qu'a éviter les fichiers temporaires.
Il reste l'avantage d'avoir des plus petits programmes réutilisable, mais un plus gros programme avec des options pour choisir la tâche à éffectuer sera plus intéressant car il permet de factoriser le code. De plus si tu peut lui d'appliquer plusieurs opération en séquence, il n'a pas besoin de recharger les données à chaque fois.
C'est le principe justement de G'MIC : Il n'y a pas un programme séparé pour chaque traitement et une utilisation avec des pipes. Il y a un gros programme et on lui donne la séquence d'opérations à appliquer.
Imagine le temps que mettrait certains des scripts fournis si il fallait transférer l'image entre chacun des traitements... Pour une photo en haute résolution avec les cannaux codés sur 16bits, ça fait un sacré ralentissement.
Pour l'intégration dans Gimp, il y a en gros deux possibilitées :
- Soit on intègre G'MIC c'est-à-dire que l'on automatise la séquence : sauvegarder, lancer G'MIC manuellement, charger ;
- Soit on intègre les fonctions de G'MIC et donc chaque fonction de G'MIC devient une fonction de Gimp.
Il me semble assez évident que, d'un point de vue utilisateur, la deuxième solution est plus puissante. Elle permet de mélanger les différentes fonctions sans se poser de questions. Mais elle est bien plus complèxes à implémenter et maintenir.
La première, par contre, à l'avantage d'être relativement simple à coder et maintenir. Bien sûr, on peut effectuer plein de petits appels et obtenir la même souplesse que dans le deuxième cas, mais c'est au prix d'un aller-retour de l'image à chaque appel.
Dans le cas ou l'on demande à G'MIC d'effectuer toute une série d'opérations, le temps de transfert est négligeable. Mais si l'on souhaite faire d'autre traitements avec Gimp, entre chaque fonction de G'MIC, ce temps de transfert est surement bien plus important.
[^] # Re: Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Je ne prétend pas être un un bon programmeur, loin de là... J'avais jetter un coup d'oeil aux papiers que tu as publier sur le sujet, et.... ce sera pour plus tard...
Ma remarque sur la lenteur de GreycStoration n'était pas une critique, mais une constatation. D'un point de vue objectif, actuellement, vu les photos pour lesquelles j'en aurais besoin, je ne peut pas me permettre d'utiliser GreycStoration systématiquement.
Et je le regrette, même si ce n'est pas de ta faute, mais du à l'algo lui-même. De la même manière que je regrette qu'il pleuve les jours où je veut tondre la pelouse : on ne peut rien y faire, mais ça nous embette quand même ;-)
GreycStoration m'a permis quand même de récupérer des photos très bruitées ou NoiseNinja n'était pas suffisant, la seule chose c'est qu'il faut avoir un peu de temps devant soit et jouer avec les paramètres.
Après il faudrais peut-être que je change mon matos, mais j'ai pas trop les moyens pour le moment ;-)
Plus généralement, avoir un exécutable indépendant qui fait une tâche bien définie et qui peut être appelé à partir d'autres programmes (plug-in GIMP ou autre) avec des transferts de données par fichiers (ou par pipes), je trouve ça loin d'être sale (je crois pas être le seul, puisque c'est quand même l'une des bases de fonctionnement du système GNU/Linux). De plus :
(1) Ca a le gros avantage de réduire la difficulté du travail d'intération, donc la maintenance globale du logiciel 'appelant'. Chaque brique étant indépendante au maximum l'une de l'autre.
J'aime la philosophie des outils unix, et les utilisent beaucoup. Il y a quand même une différence, c'est qu'ils sont prévus pour être utilisés en flux, alors que dans ce cas ce sont des échanges.
Si l'on souhaite écrire un script pour gimp qui alterne les traitement classique de Gimp et ceux de G'MIC, il va y avoir de nombreux allez-retours entre les deux.
Mais dans tous les cas, c'est principalement une affaire de goûts. Je ne fait que donner mon point de vue.
(2) Par conséquent, ca assure une plus grande pérenité au travail réalisé : si je m'amuse à interfacer G'MIC avec GEGL (qui est loin loin d'être un boulot trivial), et que dans 5 ans, GIMP se met au C++, et décide d'utiliser une autre lib (comme GIL, ou CImg , soyons fou :) ), mon utilisation de G'MIC sous GIMP est condamné, à moins de refaire un coûteux travail d'intégration avec une nouvelle lib. Au contraire, l'exécutable sera toujours fonctionnel lui (puisque conçu de manière 'self-contained' dès le départ).
Je ne te demande pas de le faire ;-) Je ne faisait que décrire mon rêve en tant qu'utilisateur. Dans tous les cas, je crois même que je préfère que tu continue de le faire comme maintenant, au moins je suis à peu près sûr qu'il va continuer à évoluer, pour mon plus grand plaisir.
Le passage à GIMP 3.0 risque d'être fatal au plug-in GREYCstoration, et je trouve ça bien dommage, car l'exécutable en ligne de commande à priori continuera d'être fonctionnel.
J'en suis beaucoup moins sûr que toi. Le passage à GEGL va permettre le traitement des photos 16bits dans Gimp (12bits dans mon cas) et donc sa prinipale limitation actuelle dans le dévellopement des fichiers RAW va être supprimée. Gimp 3.0 sera donc un très bon outils je pense pour ce genre de boulot, et au moins pour moi un plugins GreycStoration sera presque indispensable.
Écrire un node pour GEGL qui se contente d'appeler un programme externe est relativement simple, de même que la gestion des paramètres.
Donc, si personne ne le fais avant, il y a de fortes chance pour que moi je le fasse quand un Gimp basé sur Gegl sera utilisable. (pas la 2.6 qui, même si elle utilise Gegl, ne permet de manipuler les nodes dans l'interface)
[^] # Re: Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Et, non, je n'ai pas "cracker" ce logiciel. J'ai payer la licence.
[^] # Re: Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Je ne critique absolument pas ce que tu fais. Bien au contraire... J'utilise G'MIC justement pour du traitement d'image : c'est simple, efficace et léger. J'adore GreycStoration, même si je l'utilise moins depuis que j'ai cracker pour une licence noise ninja. (petite parenthèses d'ailleurs, j'ai cracker pour NN par ce que GreyStoration à pour moi deux inconvénients, le reglage des paramètres est assez obscure, et il est parfois relativement lent... et quand j'ai 200 photos d'un spectacle à développer je manque de temps pour les réglages.)
Donc je disais que je ne critique pas ton travail, c'est juste que je suis un peu maniaque quand on parle de code... et oui, désolé, on ne se refait pas. Et en plus je préfère que ce soit les autres qui changent leurs méthodes que moi ;-)
Gimp 2.4 c'est déjà un truc gros et lourd, il est dur de rentrer dedans et l'interface pour les scripts est à mon avis mal faite. Donc pour cette version à mon avis ta solution est la meilleure.
Pour les futures versions 3.0 et plus, il y aurra par contre un coeur bien plus propre et simple : GEGL, et rendre disponibles les fonction de G'MIC sous forme de node GEGL permettrait de tout utiliser de manière uniforme. L'API est simple et il y a plein de manière de l'exposé pour fire des scripts. Que ce soit un binding direct et donc des script complexes mais puissants, ou juste sous la forme du séquence de noeuds à créer et appliquer, ce qui reviens exactement au même que tes macro sous forme de paramètres.
Cela permet en plus de faire de simples nodes qui appelle G'MIC comme un programme externe et donc d'avoir un truc utilisable rapidement. Et si il y a un motivé aussi maniaque du code que moi, de porter les fonctions de G'MIC directement dans GEGL sans passer par l'appli externe. Les choses pouvant se faire progressivement.
La partie mise à jour automatique est, je pense complètement indépendante et devrais être dispo aussi bien pour les scripts G'MIC que pour les ScriptFu et autres, ça pourrait être fait avec avec un système tels que les dépots de packets des distrib, et un update automatique avec un cron.
# Merci
Posté par beagf (site web personnel) . En réponse au journal G'MIC 1.0.0 : Un outil extensible pour le traitement d'images.. Évalué à 2.
Bon boulot, même si comme toujours je suis pas un grand fan de tes convention de codage et que je reste simple utilisateur. Chacun ses goûts et je préfère que tu continu de maintenir et faire évoluer G'MIC et CImg.
Par contre pour ce qui est du Plug-in pour Gimp, l'idée me semble loin d'être si pertinente que ça. Gimp dispose déjà de toute une mécanique interne de traitement d'image. Toutes ces fonctions sont disponible pour l'écriture de script en Scheme, Python et il me semble avoir vu au moins un début de Lua. Bref de quoi faire tout ce que tu dis beaucoup plus simplement, et surtout de manière plus éfficace étant donné qu'il n'y a pas à transférer les données d'un programme à l'autre.
Bien sûr, il ne dispose pas de certaines fonction géniales de CImg et G'MIC, mais à mon avis ils serait bien plus intéressant de porter ces fonction dans Gimp et donc de bénéficier aussi de tous ce dont dispose Gimp.
Surtout avec la migration GEGL qui offre à ce niveau une souplesse de traitement géniale. Un portage des fonction de G'MIC sous la forme de node GEGL serait mon rêve...
Ça permetrait en plus de profiter des buffers et de la gestion colorimetrique de GEGL, de toutes ses fonctions bas niveau et de toutes la puissance de G'MIC.
Après je comprend que c'est difficile, étant donné les différence d'architecture interne c'est plus une réécriture qu'un portage, mais j'ai le droit de rêver...
D'un point de vue plus terre à terre, à mon avis une meilleure solution qu'un plugins resterait quand même des nodes pour GEGL qui appellent les différentes fonctions de G'MIC pour les cas ou l'on en utilise qu'une à la fois, et un node à qui l'on donne une macro G'MIC pour les cas ou l'on fait une petite chaine de traitement. (afin d'éviter les milliers de transfert...)
Au final ça permetrait d'utiliser toutes les fonction de G'MIC dans GEGL, dans le future Gimp et donc dans ses cripts et plugins, ainsi que dans tout autre outils qui utilisera GEGL. (et ça me simplifiera la vie un max....)
Promis, quand j'aurrais finit ma rédaction de thèse et que j'aurais un peu plus de temps je regarde ça sérieusement.
# Corrections...
Posté par beagf (site web personnel) . En réponse au journal Free assigné en justice par la FSF pour violation de licence GNU/GPL dans sa Freebox. Évalué à 3.
Sûrement soutenus par la FSF bien sûr, mais c'est beaucoup plus clair quand on dit qui attaque réellement.
Au moins on sait à qui va aller le fric si ils gagnent le procès.
Quand à savoir qui à raison... Pour moi, l'interprétation de Free n'est pas celle de ceux qui on rédigé la GPL, mais la GPL ne définit pas clairement la diffusion. Ce sera donc à la loi de trancher. On verra bien ce que ça donnera.
Par contre, il me semblait qu'en France les contrats et donc les licences devait être rédigés en français pour être valable. Ce qui veut dire, soit que je me trompe, soit qu'il n'y a pas de contrat entre Free et les développeurs et que donc Free n'a pas le droit d'utiliser le code.
Quelqu'un peut-il m'éclairer la dessus ?
[^] # Re: Pas forcé.
Posté par beagf (site web personnel) . En réponse au journal Chiffrage : Méthode et Utilité. Évalué à 3.
Tout simplement parce que quelque chose de compliquer à maintenir ou à utiliser ne sera tout simplement pas maintenu ou utilisé sur le moyen ou long terme.
Pour moi il y a plus de sécurité dans une solution, certes techniquement un peu moins bonne mais utilisée, qu'une solution parfaite qui ne l'est pas.
[^] # Re: Des raisons pour le recul de l'Europe ?
Posté par beagf (site web personnel) . En réponse à la dépêche Le trente-deuxième Top 500 des super-ordinateurs. Évalué à 4.
J'ai bossé sur un cluster bien plus petit que ceux-la (à côter on dirais un MO5...) mais j'en aurais eu 200 mis en drille queça n'aurait pasété plus rapide...
Il y a de gros problèmes de latence et de partage de données.Ily a grossièrement trois marches sur l'échelle :
1/ Les multi-processeurs:la latence en très faible et les resources peuvent être plus ou moins partagées ;
2/ Les clusters ou la latence est "raisonable" et la bande passante est suffisament importante pour permettre de gros échanges de données ;
2/ Les grilles ou la latence est abominable et ou il est difficile d'envisager de gros échange de données.
Sachant que pour la même puissance de calcul brute le 1/ est beaucoup plus cher que le 2/ qui est lui même beaucoup plus cher que le 3/. Mais pour la complexité de codage c'est souvent l'inverse...
Il faut prendre ce qui est le plus adapté à une tâche donnée. Dans mon cas les volumes était énormes mais un cluster était déjà disponible, donc on allait pas (et on ne pouvait pas...) racheter un multi-processeur de puissance équivalente.
Et il y a aussi le problème que ces technologies ont des limites. On ne peut pas faire un multiprocesseur aussi puissant que les meilleurs cluster ou un cluster aussi performant que les meilleures grilles.
Et à mon avis, l'idéal est une grille de bon clusters. Ce genre de trucs est en général utilisés par plein de monde avec des besoins différent, donc quand une personne à un algo qui s'adapte à la grille, il utilise un max de puissance, quand ce sont des tâche qui sont plutôt orientées clusters, on en fait tourner une sur chaque clusters. Ça permet d'utiliser au mieu les ressources sans que ça coute trop cher. (enfin, tout est relatif....)