ckyl a écrit 3877 commentaires

Je vais te révéler un secret quand tu travailles sur une plateforme qui utilise ou fourni plusieurs services tu as besoin de les installer et de les configurer et de bootstraper. Et ce quelque soit les technos utilisées. Tu aurais exactement la même chose avec une stack LAMP, Java ou autre.

Le reste n'est qu'automatisation et packaging. Je suis certain que les contributions sont les bienvenues. C'est pas bien compliqué comme travail…

Voilà on est encore reparti dans le bashing et le mepris par des utilisateurs bienveillant qui savent tout mieux que tout le monde. Pour combien de contributions effectives ?

prendront un jour le temps d'écrire une page décrivant pas à pas comment installer une instance du logiciel chez soi, afin qu'il soit simple et rapide de se lancer dans le patchage sauvage et constructif.

Genre https://github.com/nono/linuxfr.org/blob/master/README.md ?

Exemple typique du "mais" qui fait que finalement les contributions sont très théoriques ;)

C'est pas gros comme code, pas très complexe non plus. Même sans connaître les technos tu vas trouver ton chemin ca reste des modifications mineures. L'installation tu as raison mais après on à l'envie de contribuer ou pas… Y'aura toujours quelque chose.

les poules requêtes, c'est la croix et la barrière.

Heu non. C'est juste comme ça que tout développement censé se passe. C'est juste la manière de le faire qui peut changer suivant les technos/plateformes/coutumes d'où tu tombes.

Puisque apparemment on a pas les même yeux:

#!/usr/bin/env python

import Image
import ImageChops
import ImageOps

im = Image.open("google-datacenter-tech-13.jpeg")
width, height = im.size

left = im.crop(box=(0, 0, width/2, height))
left.save("left.jpg")

right = ImageOps.mirror(im.crop(box=(width/2, 0, width, height)))
right.save("right.jpg")

diff = ImageChops.difference(left, right)
diff.save("diff.jpg")

Bon après que ce soit pour des raisons esthétiques ou par ce qu'ils ont l'habitude de ne montrer que ce qu'ils ont envie de montrer c'est pas bien grâve.

Ce n'est pas une question de projet personnel ou pas. Seuls quelques projets très visible attirent quelques contributeurs. Va voir du côté des gros projets tu seras très surpris de la taille effective des équipes.

Oui, la réalité c'est que quand on se lance dans un projet personnel, recevoir des contributions est exceptionnel. Ça ne signifie pas que les contributeurs sont rares, ça signifie que les contributions se font peu autour des petits projets, car elles se font plutôt ailleurs.

La je suis pas forcément entièrement d'accord. Il est très facile de contribuer sur les petits projets. La base de code est assez petite, la pile logicielle généralement minimaliste, c'est assez peu technique et ça ne traîne pas 10 ans d'évolution et de dette technique. Quand il manque un truc ou que tu trouves un bug dans un petit projet c'est souvent facile de s'y coller et de faire quelque chose d'utile. Sur un projet fort le ticket d'entré est beaucoup beaucoup plus haut tant en compétence, qu'en temps à investir, qu'en investissement humain.

Tiens ce journal est parfaitement dans le ton. Combien ont déjà fait, et vont faire, des pull requests pour proposer les fonctionnalités qu'ils souhaitent ?

en même temps il faut aussi trouver un intérêt quelconque au projet en question…

Mais ca s'applique à quasiment tout les projets libre. Il suffit d'ouvrir un peu les yeux, de télécharger les repos quand on a un problème ou quand on veut voir quelque chose et de regarder un peu la tête des contributions. Il suffit aussi de parler avec les devs sur ces mêmes projets pour avoir plus ou moins toujours le même son de cloche. Il suffit aussi de regarder ce qu'on fait soit même.

il te demande des thunes pour les corriger, les bugs

Je note ca comme une bonne idée pour encourager les contributions ! ;) Ils mangent les enfants si tu payes pas aussi ?

Ici, c'est pour rire. Soit. Mais il y en a quand même marre. Elle est délirante cette opposition. :-)

Ce n'est pas une opposition juste un constat. D'un côté il est vrai que l'aspect collaboratif est très bons, qu'il arrive de recevoir du boulot sorti de nul part etc. D'un autre côté c'est très très rare et le pourcentage d'implication est très faible (un peu moins dans les projets visant les développeurs).

Et c'est là que le prosélytisme du type "À peu de choses près, tous les utilisateurs sont des contributeurs, ou le deviendront." devient souvent complètement déconnecté de la réalité.

L'opposition entre producteurs et consommateurs convient bien à l'idéologie du logiciel du logiciel privateur, où, en effet, la différence est bien tranchée. Un des effets indirects des licences libres est que ces différences disparaissent, à tel point que certains y voient là le principal intérêt du logiciel libre.

En pratique de toute les taches dont tu parles, celles que font les gens (sortir un paquet qui fait un configure ; make install, faire de la doc, répondre sur les forums, rapporté un bug & co) elles sont tout autant faisable avec du logiciel proprio. Les tâches restantes spécifiques au logiciel libre par contre amènent très rarement à contribution. C'est la vie. Ni voit rien d'amère, simplement essayons de rester dans la réalité.

D'ailleurs linuxfr ne semble pas échapper à la norme si j'en crois son repository git.

C'était juste pour l'anecdote marrante ;)

Voilà. Si quelqu'un te dit qu'une vis sert à tout, tu ne lui répond pas qu'il à tord par ce qu'en fait c'est le clou qui sert à tout. Mais tu lui expliques les propriétés de chaque, leurs différences d'usage et tu lui dis même qu'il existe des boulons.

Au passage pour ta remarque sur Oracle, on notera que "l'ancêtre du noSQL" qu'est BerkeleyDB appartient maintenant à Oracle (si si toi aussi tu te souviens avoir utilisé le module Perl DBM). Comme quoi ;)

Ton commentaire était bien jusqu'au dogmatique "99% des usages". Dommage, de tomber dans ce travers.

Je vais te donner le mot clé magique pour trouver les réponses à ce que tu cherches: newSQL.

En gros, historiquement on a des SGDB qui proposent une intégrité relationnel, sont ACID et offrent un support des transactions. Cela a plein de bonnes propriétés mais tu as d'un côté un problème d’impédance avec les langages objets (toujours la merde pour faire les bindings), et de l'autre ça devient souvent assez vite usine à gaz et surtout ça peut avoir du mal à scaler pour les besoins des grosses dotcom. Tu as des solutions maitres-esclaves, si tu as peu d'écritures. Et tu as des solutions reposant sur le sharding. Le problème c'est que tu arrives vite à perdre les propriétés ACID et/ou transaction en shardant, et tu vas très vite te retrouver à devoir gérer tout ça dans ton code métier (refaire tes jointures etc.).

De la est parti le noSQL qui regroupe vraiment beaucoup de choses n'ayant pas grand chose à voir ensemble si ne n'est que généralement tu perds le côté relationnel, l'ACID et les TX. C'est très cool pour certaines choses, ca répond au besoin de scalabilité pour certains mais tu te retrouves rapidement à devoir gérer plein de contraintes dans le code métier. Refaire des TX adhoc, gérer les jointures et pleins de trucs rigolos que les devs passent leur temps à foirer par ce que c'est compliqué.

Et maintenant on observe une vague de retour sur des bases qui scalent mais qui repassent sur le modèle SQL et proposent les TX ACID. Le constat est que pour un certain nombre de besoins filer une vue document, une table orientée ligne ce n'est pas suffisant et on passe son temps à tout refaire à la main. On case ça sous le nom newSQL et tu peux notamment lire le papier sur Google Spanner pour te faire une idée.

Après cette introduction grossière tu as tout les mots clés qu'il te faut pour trouver des articles beaucoup plus pertinents et intéressants sur le sujet. Encore une fois, il n'y a pas d'outil magique. Il faut bien comprendre ses besoins et sa partie métier pour choisir l'outil ou l'ensemble d'outils adaptés. Refaire du relationnel sur du noSQL est aussi merdique que l'inverse. Il faut pas non plus être prétentieux sur la scalabilité; il faut taper fort pour arriver aux limites et il vaut mieux partir sur des choses simples plutôt sur une pile hype "tout le monde utilise"; de toute façon tu auras du mal à prévoir ce qui sera limitant et faudra réécrire / ré-architecturer.

Bha dans le logiciel libre d'un côté il y a les utilisateurs qui vendent l'éloge de la communauté, de l'entraide, de la contribution spontanée, de l'audit de code à grande échelle, et du c'est toujours mieux par ce que c'est open source et de l'autre il y a les développeurs ;)

Oui bien sur c'est magique les mecs de Gnome font des mockups, et les distro implémentent tout. C'est étrange quand je regarde les paquets fait pas les distros je ne vois pas cette partie. Tu vis vraiment dans un autre monde. Il suffit de lire le thread donné dans le journal pour voir des exemples de pourquoi ils veulent la dépendance sur systemd. À partir de la on peut commencer à discuter, et expliquer qui il y d'autres solutions pour arriver au même niveau fonctionnel.

Autrement il suffit de tracer le code autour des points d'intégration pour comprendre.

ca c'est un système d'init fiable. certaines upgrades empêche de démarrer certains services…

"j'ai déjà eu un souci sur systemd avec la version de dev de Fedora". Je crois que tout les OS en branche dev que j'ai eu sont parti en miette un jour ou l'autre. C'est un peu fait pour ça. Qui plus est avec Fedora qui pousse énormément de technos et changement. Ce me semble pas un critère très fiable pour juger de quelque chose, que les branches de dev ca casse c'est pas une breaking news.

Maintenant si tu arrives à analyser la situation et pouvoir tirer un jugement objectif de son message tu es très très fort.

Pour avoir développé ma propre distrib pendant plusieurs années, je connais assez bien le "puzzle" et les scripts de démarrage.

C'est que tu n'as absolument rien compris à mon message. Gnome ils s'en balancent de la partie init. Ce qui les intéresse c'est la partie services pour que leur frontend aillent taper sur des services à l'interface connue plutôt que de se taper la merde de l' intégration avec le quadrillon de systèmes existant avec un flow d’exécution tout moisi pour faire des actions tout ce qu'il y a de plus standard. C'était le point de départ de policykit, découpler les actions d'administration privilégiées des gui. Rien de bien nouveau. C'est pas bien compliqué de comprendre que les devs d'application veulent pouvoir appeler des services qui abstrait le bordel. Si en plus on peut gérer les privilèges de manière fine c'est mieux.

Maintenant une distro, 90% du temps c'est refaire la même glue que les autres. Rien de bien intéressant ou qui fasse avancer "linux sur le desktop" ou en comprendre les problématique. Tu compiles ce qui existe et basta.

Avec systemd, gérer les services est devenu une plaie. Avant chkconfig ou ntsysv était un jeu d'enfant.

Perso je trouve pas. Pour avoir installer des services non prévu dans ma distrib cette semaine c'est clairement plus simple et DRY qu'avec un init sysV.

Ce qui ne veut pas dire qu'il n'y a pas de manques fonctionnels pour certains usages.

Aujourd'hui, on veut faire un gros bloatware au point d'avoir des interdépendances cycliques entre le processus init 1, les daemons et les applications graphiques (et je mets de coté les bibliothèques). Et sous prétexte de gagner 3s au boot !!

Heu non le pretexte pour Gnome ce n'est pas la vitesse de boot. C'est il me semble de se débarrasser de kilomètres de code système distro-dependant pour reposer sur des services afin de pouvoir proposer une bonne intégration.

Du coup je pense que quand tu dis:

La force de Linux et d'unix en général était d'être un système modulaire (un besoin, une appli), simple (tout est fichier), scriptable aisément (il suffit de piper les applis les unes derrière les autres).
Bref, sa force était de pouvoir s'adapter à tous les besoins en un minimum d'efforts.

il faut aussi réfléchir pourquoi on en arrive là. C'est facile de s'inventer un monde idéal, mais il me semble intéressant d'essayer d'entrevoir le vrai puzzle. Les desktops ont besoin de pouvoir parler au système et d'utiliser ses fonctionnalités. Mais personne n'a jamais fait un effort pour que cela soit facile, bien fait et portable. Du coup le premier qui arrive rafle le marcher.

L'ego des devs prompt a constamment réinventer la roue, supprimer puis remettre des détails, plombe le développement de Linux sur le desktop.

Cela dit, si ils arrêtent de développer y'a linux sur le desktop vu que linux sur le desktop c'est eux qui l'ont fait ;)

(et qui ne met jamais ses clignotants, pas plus qu'il ne regarde dans ses rétros).

Sur les clignos je suis pas certains que les motards aient beaucoup de leçon à donner ;)

Sur ton lien, je lis : Protections coudes et épaules homologuées CE Oui (amovibles)
Voilà, ça me suffit.

Tu me sembles bien bête sur ce point alors. Les normes de sécurité définissent un minimum à atteindre. Ça ne veut absolument pas dire que tout les équipements se valent ni qu'il est adapté à ta pratique.

Sur ce genre d'équipement, perso, c'est généralement le meilleur ratio prix/protection qui m'intéresse. Si je me foutais du niveau de protection j'en achèterai pas… Ce qui m'intéresse c'est d'être le mieux protéger possible, pas d'être en situation légale.

Bha si ca va couter plus cher qu'un CT ;)

il suffit de regarde le nombre de voiture qui fume comme des loco au charbon ou de compter le nombre de par-choque explosés …

Faudra attendre d'avoir des brêles au mazout pour comparer…

Référence de la voiture ?

Autrement encore une fois si on peut livrer une voiture sans description du cycle d'entretien (je n'en connais pas), alors c'est exactement la même chose pour tout véhicule. Identiquement tout véhicule peut être entretenu dans un réseau, hors réseau, soit même, ou pas du tout.

Dans tout les cas les deux contrôles non absolument pas le même but.

C'est déjà fait lors des révisions (et détaillé dans le manuel d'entretien, et même souvent dans le manuel utilisateur).

Tu veux dire comment exactement tout véhicule (même non motorisé) ?

Pour les 3rd party: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/doc/3RDPARTY?rev=1.974&content-type=text/plain

Pour la liste des fichiers: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/distrib/sets/lists/base/mi?rev=1.984.2.10&content-type=text/plain

Je vais essayer de te donner ce qui m'a fait choisir à l'époque où j'ai du partir de Bibble et où j'ai testé sérieusement darktable (vers les 0.9 IIRC). C'est mon analyse, je ne prétend faire aucune généralité. J'ai essayé d'inclure les évolutions qui ont eu lieu après mes tests. J'ai peu être loupé des choses dans darktable vu que je ne l'ai pas utilisé sérieusement en 1.0.

Tout d'abord Darktable vaut le coup d'être essayé et peut très certainement convenir à beaucoup de monde. C'est à mon sens la solution libre la plus crédible pour le développement de RAW. Les modules d'édition sont bons et variés, j'en trouve certain mieux foutus que Lightroom. La vitesse est correcte. Le projet était très actif et avançait à une vitesse impressionnante. Par contre le cercle de contributeur était assez restreint.

Maintenant si j'ose faire une liste des points qui m'ont et me referaient surement préférer une alternative proprio, payante et me demander d'installer un Windows la voilà:

• Pas de retouche locale. Lightroom 4 propose une retouche locale suffisament puissante pour réduire drastiquement l'usage d'un éditeur bitmap. Ca c'est absolument génial vu que tu évites la plupart des aller/retour entre les outils et que tu peux rester en non destructif presque jusqu'au bout de la chaine. La retouche locale était un peu limitée avec LR3 elle ne l'est plus.
• Pas (ou très mauvaise) gestion de bibliothèque. Celle de LR est excellente (gestion import, disque débranchés, set, déplacement des sources etc.). Utiliser le même outil pour la bibliothèque et l'édition est vraiment un plus. C'est là ou les outils Adobe marquent clairement un point: le workflow est à la fois puissant et souple. Ça vaut vraiment le coup de lire quelques bouquins de photographe pro pour voir comment ils s'organisent.
• Support à long terme et compatibilité descendante. Le développement de RAW est un suite d'opération non destructives. Par contre chaque changement du moteur peut impacter le rendu final de l'image. Adobe, pour le moment, à toujours montré un soucis de compatibilité en embarquant les anciens moteurs dans les nouvelles versions. Un vision à moyen terme était beaucoup plus brumeuse pour Darktable (Bibble s'en foutait par exemple à chaque release la suite de traitement ne donnait pas forcément le même résultat). Certains utilisateurs s'en foutent considérant qu'ils ne gardent que le produit fini (ie. le bitmap) le reste n'étant qu'une phase temporaire. Ce n'est pas mon avis, ca m'arrive de reprendre des photos de plusieurs années. Même chose pour l'évolution de la bibliothèque.
• Problème d'UX. Interface mal foutu et peu productive. J'avais écris préparé un long mail en 10+ points pour la ml mais il n'est jamais parti il faudrait que je le retrouve voir si ca s'applique toujours
• LR4 a fait des progrès impressionnant sur le traitement d'image. Par exemple la gestion du bruit est devenu juste dingue.
• Beaucoup plus anecdotique mais l'introduction de module tel que Book annonce un outil complet qui permet encore d'éviter des aller/retour qui gâche ta productivité. Pour le moment c'est encore un peut trop léger mais c'est à surveiller.

D'un autre côté LR à pour moi quelques trous béants, comme son module d'export ridicule par rapport aux capacités de Bibble, ou le manque de courbe sur le RVB.

J'ai sûrement oublié pleins de choses des deux côtes, mais comme souvent la discussion ne tient pas à un point mais à un ensemble. Bibble, darktable et d'autres me semblent parfaitement utilisables selon les critères que l'on se donne et les concessions à l'utilisation ou fonctionnelles que l'on est prêt à faire. Par contre dire qu'ils offrent la même chose ou son équivalent est souvent faux. Le faussé me semble beaucoup plus marqué du côté du bitmap.

Je n'utilise Gimp que très sporadiquement, et à chaque fois, j'ai l'impression que le logiciel ne fait pas ce que j'attends de lui,

En gros tu parles dans le vide

Après, je n'ai jamais touché à photoshop de ma vie, donc je ne peux pas comparer.

En gros tu parles dans le vide

Bref, à mon avis, c'est un faux argument pour justifier un choix non-rationnel.

Après les deux phrases précédente je me demande la valeur de ta réflexion. Tu parles d'outils que tu ne connais pas, pour des besoins que tu n'as pas. Mais les autres sont des cons alors que toi tu as fait une étude rationnelle c'est ça ?

Personnellement, ce que je trouve beaucoup plus critiquable dans Gimp, c'est l'ergonomie et le manque d'intuition. J'accepte très facilement de lire un manuel pour une interface en ligne de commande, mais une interface graphique doit être construite pour pouvoir être utilisée intuitivement (y compris en respectant les us et coutumes arbitraires, comme l'ordre des menus, etc).

C'est la connerie de la semaine.

Je peux te jurer que pour avoir un workflow efficace lire la doc et les ressources c'est nécessaire. Ce sont des outils pro, tu trouves normal d'avoir passé 5 ans à savoir utilisé Emacs, c'est la même chose ici.

Je te rejoins donc; si tu utilises Gimp 4x dans l'année tu n'obtiendras rien de plus avec Photoshop ou n'importe quel autre outil.

C'est un peu ridicule de passer son temps à prétendre qu'on a à tout prix besoin de ces 2% de fonctionnalités que personne ne comprend vraiment, et que personne dans l'équipe de Gimp (pourtant pas des quiches en traitement d'image) n'a trouvé bon d'implémenter.

Premièrement les trous ne sont pas uniquement dans les algos de traitement d'image c'est beaucoup trop simpliste et naif comme vision. Ce qui fait la supériorité des outils CS c'est qu'ils sont clairement pensés pour leurs utilisateurs cibles et ça se ressent par rapport à pas mal d'outils dont Gimp non seulement courent après la liste de features mais qui a surtout oublié que le but c'est d'utiliser.

Après comme déjà dit, on peut tout faire avec tout.