une bibliothèque METAPOST pour produire des graphiques utiles aux project managers et system desginers.
Donc une bibliothèque "bullshit-ready" tu veux dire?
Non je déconne, j'ai juste lu cette phrase d'accroche et ça m'a fait réagir au quart de tour. Je sais pas, je suis en forme aujourd'hui! :P
Pour rester dans le sujet, ça fait des jolis graphiques en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Le vocable y est: "met à disposition de manière libre et gratuite", "OpenData", "Données publiques", etc.
Ça a l'air cool, néanmoins j'ai cherché des détails plus précis que ce discours marketing. Je vois un lien "Condition de réutilisation des données" en bas, je le clique. Et là ça dit: « La réutilisation des données […] n'est autorisée qu'après avoir obtenu du ministère de l'économie et des finances une licence de réutilisation d'informations publiques contenues dans la base de données du site du prix des carburants. »
Déjà ça commence mal, je suis le lien vers l'arrêté du 28 février 2013 qui définit les conditions.
Déjà, aparté, je note que bien qu'il s'agisse clairement d'un document informatique (enfin à part s'ils utilisent encore des machines à écrire au gouvernement), ils ne savent toujours pas utiliser leurs ordis. Ils mettent en ligne une version imprimée-scannée! Si encore y avait eu une raison (papier signé, ou annoté ou quoi. Non rien. Juste ils savent pas qu'on peut "imprimer" directement dans un fichier). Fin de l'aparté, mais c'est juste que j'avais voulu faire un copier-coller de la partie intéressante, je peux même pas (je dis pas, c'est peut-être aussi sur Legifrance, mais quand même! Dans ce cas là, ils donnent un lien vers le texte utilisable. Pour un site sur l'OpenData, ça le fout mal).
Donc en gros, sur le papier que je peux même pas copier-coller, ça dit que pour réutiliser sur OSM, c'est considéré comme réutilisation commerciale (« en vue de l'élaboration d'un […] service destiné à être mis à disposition de tiers à titre gratuit ou onéreux »). Ok on sent venir la facture.
Pire cela pourrait éventuellement être classé comme utilisation commerciale "intermédiaire". C'est pas clair si on doit considérer OSM comme « destiné[NDR: gras de moi] à être mis à disposition, à titre gracieux ou payant, à d'autres opérateurs économiques pour une réutilisation commerciale », mais c'est clairement une des utilisations.
Bon bah si on considère cela comme utilisation commerciale finale, c'est 5000 EUR par an les 2 premières années, puis 10.000 par an. Si on est intermédiaire, c'est 38.500 par an.
Bon voilà, c'est bien pour les particuliers qui peuvent aller direct sur ce site gratos, peut-être bien aussi pour Google et consort, pour qui c'est une source d'info fiable (et 38.500 par an, c'est une pichenette pour eux), mais c'est pas encore cela pour OSM. Déjà financièrement, mais même s'ils avaient les sous, ils ne peuvent mélanger ces données à leurs données en CC by-sa.
Quant à l'OpenData? On repassera. C'est un peu des guignols, ou alors plutôt ils nous prennent pour des cons.
Pourtant je me dis que si c'est un problème de financer les caisses de l'état, ils pourraient faire de la double licence: CC by-sa + une licence proprio chère. Une boîte comme Google ne peut mélanger du CC by-sa à ses données, et donc paieraient, car ils ne peuvent se permettre (voire n'ont pas le droit puisqu'ils ont eux-même des accords) de licencier leur propre données géographiques ainsi (et s'ils le faisaient, ben ce serait un bien pour le monde!). Tous ceux qui font du CC by-sa comme OSM pourraient y accéder. C'est pourtant pas trop dur de trouver des solutions raisonnables pour avoir des données publiques réelles, pour le bien du peuple, tout en remplissant un peu les caisses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Y a pas beaucoup de Jehan sur Terre. J'en ai déjà rencontré une fois y a des années sur le web (un vrai Jehan, parce qu'y aussi ceux dont c'est juste un pseudo; comme la Jehane qui venait sur linuxfr, il me semble lui avoir demandé un jour, et elle m'avait dit que c'était un pseudo. Enfin il me semble), mais j'attends encore d'en rencontrer un en face de moi (sauf celui dans mon mirroir, mais il m'énerve à me copier, celui-là!).
Donc oui.
Quels liens entretiens-tu avec apertus° ?
Ben je m'y suis intéressé y a plus d'un an quand j'en ai entendu parler pour la première fois, et je suis donc rentré dans l'équipe comme développeur software. Dans les faits cependant, je regrette presque car à part ajouter quelques petites fonctionnalités sur des scripts que certains cinéastes de l'équipe utilisent pour traiter leurs rushes, et des discussions (sur notamment le choix d'un NLE comme "référence" pour démontrer un workflow Libre complet), je ne me suis jamais donné le temps d'en faire plus. C'est un choix, parce qu'il faut bien faire des priorités (mes projets persos), et ce n'est pas le point que je regrette. Je ne regrette pas non plus de m'être approché du projet car je le trouve toujours aussi cool (j'ai d'ailleurs réservé ma caméra par le crowdfunding). Ce que je regrette, c'est que ça fait un peu "promesse pas tenu", quand on se propose à contribuer et qu'au final (oups), on prend pas le temps.
Mais personne n'en est mort. ;-)
Enfin bon, je suis toujours dans la mailing list "team", et je donne mon avis de temps en temps sur les sujets ou je peux (généraux ou software). Mais dernièrement ça se limite là. Ça me permet tout de même d'avoir une vue de première main sur les dernières nouvelles et les choix et décisions pris. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok. Bon je suis autant dans le flou que toi côté matériel. Donc peut-être que je dis de grosses conneries, mais justement en voyant les diverses simulations 3D (par exemple sur la page de financement), ainsi que les photos de l'Alpha dans le blog (voir: https://www.apertus.org/axiom-beta-in-the-lab-axiom-alpha-in-the-field-article-2014), ben j'avais justement l'impression que la caméra pourrait être très petite, même plus petite que la caméra autonome de ta photo.
Alors bien sûr, faut imaginer une boîte autour de ce prototype à nu, ça aura pas du tout cette forme, etc. Mais on voit que c'est pas énorme quand même.
J'ai l'impression que ce qui devrait prendre le plus de place dans la caméra sera les objectifs (quand on voit les objectifs de fou qu'ils utilisent dans le cinéma), mais bon là, y a rien à faire, c'est le cas toujours, et surtout quelqu'un qui veut juste une petite caméra portable pour filmer un entretien pourra juste mettre un petit objectif et il a sa cam transportable.
Enfin j'espère! Encore une fois, je me suis pas occupé du hardware du tout dans ce projet! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
D'ailleurs, à moins d'une prouesse technique brillantissime, l'apertus ne sera pas une caméra "transportable".
J'ai pas trop compris pourquoi tu dis cela. J'avais un peu cette peur où tout début quand le projet Apertus a commencé à faire parler de lui et que j'ai regardé ce qui avait été fait du côté de Elphel. Mais depuis les choses ont énormément évolué et la description est assez claire.
Alors oui, de base, y a juste une boîte. Il manque un viseur/écran LCD et des contrôles (bouton, ou sensitivité à la pression, etc.). Pour cela, en attendant, on peut connecter une machine en ethernet/wifi/usb/autre, et tu vas me dire en effet, c'est moyen transportable. Sauf que maintenant on fait des machines super puissantes et super petites. Et je dirais même plus: la plupart des gens ont désormais un ordi dans leur poche (smartphone). Pouvoir contrôler une petite caméra (et avoir une prévisualisation) à distance avec son smartphone, certains te diront que c'est au contraire bien plus transportable qu'un écran LCD et des boutons sur la boîte.
Note que la version prototype actuelle est un serveur web, donc n'importe quel smartphone, sans logiciel particulier autre qu'un navigateur, peut se connecter à la caméra, modifier les divers paramètres (le prototype Alpha propose quelques boutons pour contrôler la vitesse d'ouverture, les profiles de couleur, quelques autre paramètres, et afficher quelques données genre histogramme temps réel, courbes de couleur…). Ça n'empêchera pas d'avoir des logiciels plus sophistiqués plus tard qui permettront plus. Mais déjà y a une base standard et simple.
Ensuite reste le problème de l'enregistrement. Les capacités de base (interne en microSD) sont certes très limitées en vitesse comme en espace. Tu peux aussi connecter un ordi à distance en wifi (ou en ethernet pour aller plus vite), et j'admets que ce n'est pas le plus "transportable" (quoique un petit ordi dans le sac à dos, ça reste léger et peu encombrant). Si tu as des besoins élevés (raw 4K ou FullHD, probablement pour la plupart qui veulent cette caméra), tu voudras connecter une interface d'enregistrement externe. Et je suis persuadé que le module d'enregistrement HDMI sera l'un des premiers modules à sortir quasi en même temps que la caméra (d'ailleurs il est cité dans la page de financement).
Donc au final, la caméra + l'objectif (comme toute caméra de ciné) + le module d'enregistrement + module alimentation + écran LCD, franchement ce sera pas gros. N'importe quelle caméra que je vois sur un tournage serait au moins aussi grosse (en générale elle sont toutes très grosses sur les tournages si vous avez déjà vu).
Et y aurait moyen de la faire tout de même passer dans des situations très "transportées" au contraire. Un voyage en voiture? Juste la base + objectif dehors (sur le capot ou le toit du véhicule par exemple), relié à un petit ordi pour visualiser et contrôler depuis l'intérieur. On doit même pouvoir l'installer sur une moto avec ce genre de système (les caméras de ciné classiques sur une moto, c'est plus casse-gueule). Même à pied, y a des moyens d'arranger justement pour porter du poids dans le sac et ne porter que la partie visée à la main.
Enfin voilà, je pense que ça se défend au niveau transportabilité. Mais peut-être veux-tu étayer ta pensée, j'ai peut-être loupé quelque chose…
Ou alors quand tu dis "transportable", tu parles des mini-caméras genre gopro? AXIOM n'a jamais aspiré à ce marché là. Le but a toujours été de faire une caméra pour le cinéma.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je sais pas si c'est une vraie question ou rhétorique (histoire de signaler un cas où la syntaxe est en effet peu claire), mais au cas où, je vais y répondre. :-)
int* i,j;
i est un pointeur sur entier, j est un entier. C'est je pense la raison pour laquelle beaucoup de projets vont plutôt écrire l'étoile à côté de la variable, non à côté du type, pour qu'on voit bien à quelle variable cela s'associe:
int *i, j;
Enfin si tu voulais avoir 2 pointeurs, tu écrirais:
int *i, *j;
Note que je n'écris dorénavant plus jamais de déclaration de cette sorte, car je trouve en effet cela abscons, et je me posais aussi la question à une époque (jusqu'à ce qu'un jour, je teste). Maintenant je déclare une variable par ligne, même si c'est le même type. Je trouve cela plus clair de cette façons. Au moins, plus de question. :-)
const char *p' vs 'char * const p'.
Ça a l'air d'un cas différent, mais c'est en fait très similaire à ce que tu as au dessus (en gros), c'est à dire que tu dois associer le '*' avec ce qu'il y a après. const char *p -> tu as d'un côté const char, de l'autre p. Donc ça signifie que p est un pointeur sur const char. Le pointeur lui-même n'est pas constant (tu peux changer la valeur de p autant que tu veux). Mais la valeur pointée par p elle ne peut pas changer (tu peux cependant faire repointer vers une autre valeur différente, ce qui a un résultat similaire). char * const p -> d'un côté char, de l'autre const p. Cela signifie donc que p est un pointeur sur un char (variable). Tu peux changer cette valeur pointée (le char) autant que tu veux, par contre, tu ne peux plus jamais changer le pointeur p lui-même après son initialisation.
C'est compliqué, mais faut s'y retrouver avec des associations de ce genre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La différence? C'est pas de l'OpenHardware. Alors oui le prix affiché pour ces caméras semble moins cher que le prix attendu pour AXIOM. Mais déjà ce prix annoncé par Apertus n'est pas vraiment décisif, et a été pris large en considérant les prix marché. Le but étant que le prix final ne devrait être qu'inférieur (bonne nouvelle!), identique au pire, mais surtout pas supérieur. Je cite:
Current price values are gross estimates and depending on actual production volume might be a lot lower.
Donc il y a de bonnes chances que le prix de production soit en réalité bien en dessous. Cela dépendra du volume de production (et comme la campagne a du succès, il y a de bonnes chances que le volume de prod soit important dès les premiers modèles, ou que les usines fassent de bons prix car ils pourraient y voir du bon potentiel commercial sur le long terme).
Rappelez-vous. Les premières annonces du projet indiquaient un vague "moins de 10,000 EUR". Maintenant on est dans les 1900/2300 EUR pour le prix de production, et le double (soit ~ 3800/4600 EUR) pour le prix de vente normal. Et ce prix a encore de bonnes chances de baisser (peut-être dès les premières productions, ou les suivantes).
Mais comme je disais, ce n'est pas le point important pour autant. OpenHardware l'est. Qu'est-ce que cela signifie:
1/ customizable: à peine annoncé, deux capteurs sont proposés. Selon les demandes (ou même des contributions communautaires), d'autres capteurs pourront être proposés. Y a deux jours par exemple, quelqu'un nous demandait si on considérait CMV20000 aussi (mais l'interface est complètement différente, donc la réponse fut qu'il y aurait du développement spécifique à faire, et aussi que le prix d'achat est quasi double de celui du CMV12000, donc ça monterait bien le prix du tout). Mais ça se limite pas au capteur. Tout élément pourrait être modifiable, et les modules attachables peuvent être développés (et vendus!) par tout un chacun, pour tout type de besoin.
Ça veut dire qu'on peut s'attendre à des modèles plus chers mais de bien meilleure qualité, mais aussi des modèles moins cher si y a la demande (mais en voyant le succès des modèles avec de meilleures composants dans le financement, j'ai l'impression que les gens préfèrent payer plus pour mieux que l'inverse).
Les autres caméras? Y a pas de choix. Il peut y avoir des options, mais même si y en avait des dizaines, ce serait toujours limité. Une seule entreprise est au volant, et ils ont un contrôle ferme sur le produit. Je doute même que les utilisateurs puissent ouvrir la bête (enfin techniquement on peut toujours, mais au niveau garantie, cela la cassera sûrement aux yeux de l'entreprise).
2/ réparable: tu casses ta petite caméra commerciale à 2000 EUR, seule l'entreprise vendeuse est à même de réparer, et il y a de bonnes chances que le devis qu'ils te feront sera quasi aussi gros que le prix du nouveau modèle (tu te rends compte, t'as le modèle d'y a un an! C'est has-been!). Bon bah on achète le nouveau modèle alors, hein? Qui ne connaît pas cela? Qui n'a jamais vécu cela avec d'autres produits? C'est le business modèle de la plupart des produits électroniques "pas cher" de nos jours. Certains appellent cela l'obsolescence programmée.
Tu casses ton AXIOM? C'est fait pour être réparé, donc déjà tu peux être assuré qu'ils ne joueront pas le jeu de te faire des devis hors de prix pour juste changer une résistance qui a grillé (parce que t'y connais rien). Et quoi, tu veux pas attendre? Ben t'as les plans! Soit tu t'y connais et tu peux réparer toi-même aussi, soit par exemple, tu peux aller à l'électronicien du coin. Peut-être même que tu as quelqu'un dans ton équipe de tournage qui s'y connaît suffisamment en électro (un chef op, ou que sais-je).
En gros, même si Apertus décidait soudain de devenir un vilain et de te faire payer des sommes folles pour changer ta résistance, tu as toujours plein d'alternatives viables.
3/ mettable à jour (donc jamais obsolète): tu veux un nouveau modèle? Qu'à cela ne tienne! Envoie ta caméra et on te l'installe (ou encore une fois, installe toi même; ou achète le composant et paye un électronicien!). Pourquoi racheter tout un appareil et polluer/gâcher/jeter toute ton ancienne caméra, encore parfaitement fonctionnelle, quand le nouveau modèle est globalement la même chose avec un ou deux composants différents, et le circuit imprimé mis à jour?
Mise à jour moins chère, moins de déchets, plus économique et écologique donc. L'OpenHardware c'est aussi ça. Apertus a déjà même prévu la mise à jour vers AXIOM Gamma, en annonçant que les financeurs auraient là encore un prix d'ami.
Crowd funding backers will be offered an exclusive upgrade path to the production version of AXIOM. (probably called AXIOM Gamma) Essential components, like image sensors will be reusable as well.
On parle bien de mise à jour, pas de "prix d'ami pour acheter en plus la version gamma". Non ce sera: "t'envoies ta beta, on ouvre la bête, et on la transforme en gamma, et tadaaaaa"!
C'est un procédé classique en OpenHardware, et j'ai déjà vu similaire sur d'autres produits pour la mise à jour. En gros, on n'essaie plus de cacher "comment ça marche". La plupart des produits commerciaux sont vendus comme des sortes de "bloc" tout-en-un, une boite noire indissociable de son contenu. Tu veux mieux? Tu changes le tout et tu revends (bien moins cher que l'achat) ou tu jettes.
Avec l'OpenHardware, on fait prendre conscience aux gens que leurs machines ne sont pas des boites magiques dont on ne comprends pas le fonctionnement et la mécanique interne. Ce sont bien des machines créées de multiples éléments associés les uns aux autres, réparables, changeables indépendamment du reste, et mettables à jour. Alors tu n'as pas nécessairement à être électronicien et à comprendre le détail pour comprendre cela. De même que sans être mécanicien, je sais que mon véhicule est composé de pleins de pièces que je peux changer individuellement, et que je n'ai pas juste à changer de voiture si elle se met à avoir des problèmes (quoique même là, à des prix bien plus élevés pourtant, les entreprises essaient de plus en plus de jouer ce jeu là de la "boite noire magique", et pas mal d'acheteurs avec les moyens jouent le jeu de racheter tous les 2/3 ans pour un rien).
C'est bien plus sain. C'est aussi plus juste envers les acheteurs et ça prend moins les gens pour des cons. Enfin même si cela pourrait sembler plus cher à l'achat, si c'est un produit dont on a vraiment besoin (on l'utilise vraiment beaucoup), il y a de fortes chances que cela s'avère moins cher sur le long terme.
Et bonus, c'est aussi plus écologique.
En tous cas, quand je vois le succès de la campagne, je pense pouvoir dire que beaucoup de gens voient tout cela et ne sont pas dupes. Donc vos liens et vos modèles "plus adaptés" pour des "petites structures". Ben je dis juste: non, rien à voir. Elles ne pourront jamais concurrencer un modèle OpenHardware avec un vrai élan communautaire derrière.
D'ailleurs pour revenir sur le sujet des amateurs/(semi-)professionnels, on peut considérer que ces modèles que vous nommez resteront à jamais pour les amateurs/semi-pro (jamais un pro avec des moyens ne s'achètera une BlackMagic à 2000 EUR qui peut le lâcher du jour au lendemain et avec pas mal de limitations), alors qu'AXIOM va très probablement pouvoir évoluer vers le milieu professionnel également, que ce soit parce qu'avec les options, on va pouvoir avoir des versions bien plus performantes en achetant d'autres composants et en les faisant installer, mais surtout parce qu'on pourra avoir du service derrière! Je rappelle que c'est ce qui joue le plus en milieu pro. On veut pouvoir payer pour avoir un vrai service (le but n'étant pas que ta caméra lâche en milieu de tournage et que tu perdes plusieurs journées de tournage, ce qui coûte bien plus cher que ta caméra!).
AXIOM pourra avoir tout cela une fois que la technique se sera stabilisée (à partir ou après AXIOM Gamma donc), et que des services pourront se mettre en place.
C'est donc un produit qui peut aussi évoluer avec vous. Si vous passez du statut amateur au semi-pro puis pro, la caméra peut vous suivre, obtenir des améliorations, puis vous pouvez avoir des supports de service client adaptés pour vos tournages. Ce n'est donc plus seulement "pas cher pour petite structure", mais cela tout à fait devenir "caméra pro de qualité et avec service adapté" avec le temps. AXIOM pourra jouer sur tous les terrains dans le futur. C'est adaptable. Et ça, c'est aussi un pouvoir énorme.
Ensuite tout cela est à vérifier dans le futur. Mais cela reste le potentiel de l'OpenHardware (et cela sera toujours le cas même si ce projet en particulier devait ne pas réussir ou mal tourner, on ne sait jamais). C'est la "promesse d'un monde meilleur", et c'est ce pour quoi les gens paient aujourd'hui quand ils financent le projet. Ils ne paient pas juste pour une caméra. Comme tu dis, ils peuvent en avoir une tout aussi bien, moins chère, là tout de suite (d'ailleurs je suis persuadé que plusieurs des financeurs d'AXIOM ont déjà certains des modèles que vous citez!). Non ils paient pour faire avancer la société, aller plus loin et faire un pari sur l'avenir. Et si cela ne fonctionne pas avec ce projet là, cela peut fonctionner avec le suivant. Mais si on n'aide pas les premiers, les pionniers, cela ne fait que retarder ceux qui apporteront vraiment le changement (car ils se reposeront sur l'expérience acquise des prédécesseurs).
Acheter un de ces modèles commerciaux que vous citez? Ben ça ne fait que confirmer le statu-quo. C'est pas si grave en soi, mais ensuite c'est un choix de vie. :-)
Je pense perso que c'est important.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Alors dans le milieu amateur ou semi-professionnel, ils n'ont pas les mêmes fonds, mais ils sont tout de même habitué à mettre plus que le particulier dans leur matériel vidéo et audio.
Et par curiosité, quel est le besoin d'une caméra 4K pour un tel public ?
Ben écoute, y a pas si longtemps, je suis sûr que plein de gens se demandaient l'utilité du téléphone portable pour le grand public (hors professionnels). La technologie avance, et le grand public aussi aime l'idée de pouvoir y accéder, plutôt que cela soit réservé à une "élite" professionnel qui revendique son irremplaçabilité par du matériel hors de prix.
Donc oui, maintenant on fait de la super méga définition au ciné. Alors pourquoi des amateurs n'auraient pas envie, ni le droit, de pouvoir y accéder aussi (en "actif", avec création perso, et plus juste en "passif", devant sa télé)?
C'est bien ça aussi l'OpenHardware: donner accès aux gens à la connaissance et à l'action pour des choses qui étaient réservés aux "pros" jusque là (de même que le FLOSS a fait la même chose pour le logiciel).
Ensuite ça dépend des passions et intérêts. Certains aiment les véhicules et vont dépenser plus d'argent dedans, pourquoi d'autres ne pourraient aimer faire des films?
Aussi je fais clairement la différence entre professionel/amateur et qualité. Dans tous les domaines, je connais des professionnels (= des gars dont "c"'est le métier) totalement incompétent et des amateurs d'un niveau à faire pâlir nombre des dits professionnels. Une fois cela mis en place, je soutiens donc qu'il n'y a pas de raison à ce que les amateurs n'aient pas accès à du matériel de qualité si c'est techniquement/financièrement possible.
Alors pour les amateurs de l'espace, il est clair qu'ils n'auront pas accès à une navette spatiale de sitôt (cas du "pas financièrement possible"), comme ceux amateurs de l'énergie ne pourront s'amuser à faire leur mini-centrale nucléaire à la maison (cas "pas techniquement, voire légalement, possible"). Par contre, franchement avec la technologie d'aujourd'hui, limiter le matos vidéo de qualité aux pros par des prix exorbitants, c'est une limitation artificielle maintenue par des intérêts financiers. Les pros pourront toujours avoir plus de toutes façons: quand tu loues une caméra dans le cinéma, ce qui coûte cher, c'est pas seulement la caméra, c'est aussi les garanties, le service (la caméra tombe en panne, t'en reçois un remplacement dans les 2/3 heures). Le particulier doit faire bien plus gaffe à son matos, doit se débrouiller seul en cas de problème, doit bidouiller, etc. Dans toute technologie, ce qui coûte le plus cher, c'est l'humain (service, support), pas le matos, et c'est très bien (je trouve en effet que le temps qu'un être humain va partager pour régler le problème d'autrui a beaucoup plus de valeur qu'un bout de métal/plastique).
Donc quel est le "besoin"? Y en a pas. Comme y a pas non plus de "besoin" chez les pros (des pros peuvent faire sans 4K aussi. C'est même un concept chez certains. J'ai vu des films pros tournés entièrement sur des téléphones, et c'était le concept du film). Par contre "envie", oui, il peut ou non y en avoir. Et dans ce cas là, si c'est techniquement possible de donner accès au plus grand monde par l'OpenHardware, je dis: ben c'est cool.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
En ce moment ce sont plutôt les "ingénieurs hardware" qui ont oeuvrés,
Oui mais uniquement car ils n'ont que cela. Je peux te dire que sur la liste de développement du projet, à chaque fois qu'un développeur se présentait, on lui sautait dessus pour l'accueillir. Mais à ma connaissance aucun n'a réellement fait de contribution approfondie. Par contre y a plus de mecs dans le hardware qui sont arrivés et qui ont effectivement livré quelque chose. Alors bien sûr, les mecs du hardware, ils peuvent aussi développer. Mais bon avoir aussi d'autres gens plus spécialisés en software serait pas un mal.
Ensuite clairement le hardware est la priorité pour le moment, donc c'est pas le pire des cas. Mais je peux te dire que vu de l'intérieur, ne pas avoir plus avancé aussi au niveau software, en parallèle, c'était pas un choix.
Donc l'Axiom Beta qui est opérationnelle va être lâchée dans la nature et l'une des cibles (l'autre étant les vidéastes) est clairement celle des développeurs.
Comme dit plus bas, c'est Alpha qui est opérationnelle. Beta sera le résultat du financement.
Sinon la cible de Beta, côté vidéaste, c'est seulement une partie d'entre eux, ceux qui ont pas peur du côté technique et de devoir un peu plus bidouiller que la moyenne. Pour les vidéastes de manière général (ceux qui veulent pas trop se poser de question également), ce sera plutôt Gamma.
Par contre oui les développeurs, ingénieurs, techniciens, scientifiques et cinéastes bidouilleurs sont plus la cible directe de Beta. Ensuite faut pas croire, les cinéastes qui veulent pas de caméra trop expérimentale, mais ont des sous et sont prêts à faire avancer le schmilblick pour arriver plus tard à Gamma qu'ils pourront alors acquérir sont aussi invités à financer le projet!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Bref, l’Axiom utilisera très probablement un capteur APS-C 22.8×16.9mm qui a l’avantage de contenir le format Super 35. Et même s’il était de très bonne qualité, ça ne pourrait pas séduire un photographe exigeant qui a l’habitude d’utiliser au minimum du Plein-Format 24×36mm, surtout que les optiques haut de gamme sont faites pour, et là, on trouve des boîtiers à 2000€.
Ça c'est ce qu'ils ont fait avec l'AXIOM Alpha (prototype actuel). L'AXIOM Beta (le résultat du financement) sera le Truesense KAC12040 de base, mais ils prévoient de proposer des options pour d'autres capteurs (lire AXIOM Beta). Cependant cela dépendra du succès du financement (des "stretch goals").
En fait ça dépendra donc beaucoup de ce que les gens sont prêts à mettre pour passer un cran dans la qualité d'image.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
1) peuvent se permettre de mettre plusieurs milliers d'euros pour une caméra professionnelle?
D'après moi clairement. Dans le milieu du cinéma, ils mettent vraiment des sommes faramineuses. Alors dans le milieu amateur ou semi-professionnel, ils n'ont pas les mêmes fonds, mais ils sont tout de même habitué à mettre plus que le particulier dans leur matériel vidéo et audio.
Ensuite le financement parviendra-t-il à son but? L'avenir nous le dira mais même un échec ne pourra être interprété comme un échec plus générique de l'open-hardware dans le cinéma. Plein d'autres raisons peuvent expliquer cela. De toutes façons, perso j'y crois.
2)qui ne l'auraient pas déjà fait en s'achetant un autre appareil du commerce,
Bah les gens sont prêts à changer de matos s'il le faut. Et puis c'est pas comme si y a pas des nouveaux tous les ans (comme dans tous les métiers: les jeunes sont les futurs vieux!). C'est absurde de supposer que tous les cinéastes ont déjà leur matos pour les prochaines années. Dans ce cas là, y aurait pas qu'Apertus dans la merde. Le marché des caméras de cinéma serait verrouillé et plein de boites couleraient! uhuh
3)prendraient le risque, pour un tel montant, d'un appareil non éprouvé?
Ben ça reste raisonnable pour beaucoup de gens au contraire. Une location de caméra pour un film ciné à petit budget est déjà plusieurs fois ce prix là.
L'AXIOM BETA est la BETA d'une caméra qui va évoluer pour arriver à l'ALPHA
Euh non c'est l'inverse. Alpha, c'est fait, c'est maintenant. C'est le prototype qui est présenté maintenant tout de suite, les premiers tests, les premiers essais. Puis on s'est rendu compte des erreurs de conception, de jeunesse, le fait que ce premier prototype est trop cher et compliqué à dupliquer, que plusieurs des choix et designs électroniques n'étaient pas idéaux, etc. Beta sera donc le résultat suite au financement collaboratif, bénéficiaire de ce qu'on apprend de nos erreurs, et sera ce que les "financeurs" recevront à la fin.
Plus tard y aura gamma, qui devrait être un modèle plus "prêt à l'emploi". Et j'imagine que si ça continue comme ça, un jour il pourrait y avoir delta, etc. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est bizarre, la page dit "Laptops are currently unsupported". Quelle est la différence entre un ordi portable et de bureau? C'est la même chose fondamentalement. C'est la première fois que je vois un programme faire une telle différence, et je me demande si le programme refusera de marcher si je le lance depuis un portable, ou bien si le site refusera mes rapports de compatibilité s'il détecte que je les ai envoyé depuis un portable…
Sinon la seconde chose qui me chagrine est que pour rapporter du matériel, il est écrit qu'on doit utiliser une des distribs appuyées par la FSF (c'est à dire pas grand chose d'utilisé, ça fait vraiment un micro pourcentage des utilisateurs), ou une Debian avec seulement le dépôt "main" activé (là y en a plus, mais ce choix est arbitraire).
Encore une fois, je me demande ce qu'il se passe si on envoie un rapport de matos fait depuis une autre distrib. Sera-t-elle refusée? Non parce que cela rend le site beaucoup moins utile si quelques pourcents des utilisateurs GNU/Linux seulement peuvent rapporter.
Bien sûr, je comprends tout à fait qu'ils limitent leur site aux matos qui ne marchent qu'avec du Libre, tout comme je comprends qu'ils appuient particulièrement les distribs qui prennent le parti de ne rien accepter de non-Libre. C'est la FSF, c'est leur rôle. Par contre tout le monde aurait à y gagner si tout le monde pouvait faire des rapports de matos. Y a des moyens de savoir si un matériel donné utilise des drivers/firmware non-Libre.
Sans compter que ça veut rien dire si les dépôts non-Libres d'une Debian sont pas activés au moment du test: il suffit qu'ils aient été activés à un moment pour avoir installé des drivers proprios à ce moment là. De même qu'il est possible aussi de désactiver les dépôts non-Libre sur toute (ou presque, je sais pas si y a des distribs qui ne séparent pas le non-Libre dans un dépôt à part, mais ce serait l'exception) distrib GNU. Sur le coup, ils mettent uniquement Debian à part parce que c'est une collaboration entre FSF et eux. Mais c'est loin d'être une différenciation justifiée.
D'ailleurs même les distribs 100% Libres, les utilisateurs ont pu installer "à la main" des drivers non-Libres à un moment.
Enfin voilà, ce serait bien plus logique de faire une détection automatique du driver utilisé pour un composant particulier, de l'envoyer avec le rapport, et là les utilisateurs qui savent peuvent flagger le driver comme Libre ou non (et ne pas afficher sur le site tout rapport avec un driver non-Libre). Y aurait donc une table dans la base pour les drivers qui dise s'il est Libre ou non et s'il utilise un blob binaire ou non. L'utilisateur n'aura donc pas à se poser de question et pourra envoyer son rapport, qui sera automatiquement ajouté si on sait que le driver associé est Libre, ou refusé avec message explicatif dans le cas contraire. Si c'est un driver inconnu, le rapport peut rester en attente d'autres membres de la communauté à même de dire si c'est un driver Libre ou pas.
D'ailleurs je suis à peu près sûr que leur client envoie déjà automatiquement le driver utilisé au serveur (en tous cas, je vois qu'ils listent les drivers par périphérique sur le site), y a plus qu'à (comme on dit) implémenter le système de validation sur le site. Deuxième chose serait de s'assurer qu'ils l'acceptent et qu'ils soient pas trop arrêté sur leur décision de privilégier certaines distribs.
Je jetterai un œil plus tard, y a peut-être un patch à faire et à leur envoyer. :-)
Mais comme je dis toujours, si quelqu'un aime l'idée et veut proposer avant moi, faites vous plaisir! J'ai pas exclusivité sur les idées et je serais pas contre utiliser mon temps autrement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pour répondre au message originel: c'est bien leur but de coupler ce projet avec un projet de montage. En fait ils sont très ouverts sur "comment", ils veulent juste un bon logiciel. Cela pourrait être un logiciel existant qu'ils pourraient améliorer pour le rendre pro et compatible à leurs exigences; cela pourrait être faire un logiciel eux-même qui répondra parfaitement au cahier des charges (oui je sais, c'est trop gros, mais en même temps, ils font aussi une caméra à partir de zéro, ça aussi c'est gros!); cela pourrait se mettre en collaboration avec un projet existant pour travailler main dans la main (y a eu un tel rapprochement avec une société qui faisait un logiciel de montage OpenSource dont j'avais jamais entendu parler. Mais ça n'est jamais allé plus loin que la discussion, sauf si j'ai loupé qqch).
Dans tous les cas, il manque une chose dans leur projet: des développeurs. C'est marrant mais de notre côté dév, on a toujours l'impression qu'on n'a que des développeurs et qu'il manque tous les autres. Ben de leur côté, ils ont réussi à chopper plein de mecs super compétents en électronique, qui ont même déjà participé à des élaborations de caméras du marché pour certains, mais les dévs? Que dalle. Oh y a eu pas mal de mecs qui se sont proposés (dont moi), mais au final sans vrai résultat (j'ai d'autres priorités malheureusement dans l'immédiat). C'est donc assez drôle et même socialement intéressant de constater que le problème n'est pas qu'il manque de mecs pour le hardware, mais c'est juste qu'on n'arrive pas à se mettre ensemble plus.
Enfin oui, tout ça pour dire: c'est l'idée, mais ils n'attendent que les dévs. Qu'attendez-vous?! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Pourrait-on rajouter cette info dans la dépêche. Voici l'email envoyé sur la mailing liste communautaire:
To participate in the "hopefully" very successful launch of the campaign tomorrow you are all invited to the IRC Launch party starting 1 hour before the campaign launches at 9 AM (Central European Summer Time)
I will share some treasures from the AXIOM development history like renderings how we anticipated the camera to look over 3 years ago and we can just have a good time, like a real party just without seeing each other :)
Hope to see you on IRC!
En gros, une heure avant la fin du décompte, ils proposent à toute la communauté de se rendre sur IRC pour discuter, et ils partageront quelques "trésors" de l'histoire du développement d'AXIOM.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Je suis assez d'accord. Pour moi cinelerra, cela fait longtemps que je ne le considère même plus dans mes comparaisons et tests de logiciels de montage vidéo.
Les dernières fois où j'ai essayé de l'utiliser, il y a peut-être 2/3 années de cela, il était tout simplement instable. Il crashait toutes les 10 secs pour un oui ou un non. Donc franchement j'ai laissé tomber avant même de savoir si le logiciel "pourrait" être bien ou non, s'il ne se crashait pas constamment.
Les fois où j'ai essayé de le compiler, à peu près à la même période, soit 2/3 ans auparavant aussi (donc peut-être qu'à l'époque je m'y connaissais moins aussi), c'était la croix et la bannière.
Il n'est même plus dispo de base dans pas mal de distributions. Déjà parce qu'il dépend fondamentalement de la libfaac qui a des problèmes de brevets (or si certains logiciels ont une dépendance optionnelle, cinelerra apparemment ne peut pas faire grand chose sans libfaac). Donc les distribs qui n'ont pas de dépôts teintés ne proposent pas cinelerra (par exemple: mageia). D'ailleurs je viens de vérifier, même si ma Linux Mint propose libfaac, elle, ben y a pas de cinelerra pour autant dans les dépôts. C'est clairement plus un logiciel prioritaire pour personne.
Enfin regarde le résumé des commits du projet communautaire sur les dernières années sur ce site: https://www.openhub.net/p/cinelerra/commits/summary
Y a eu quasi absence de commits entre 2007 et 2014! C'était donc un projet mort. Je remarque d'ailleurs que ça reprend seulement depuis avril 2014 (tout frais! Je jetterai un œil de temps en temps pour voir si le projet se relance vraiment ou si c'est juste un soubresaut. Si ça continue à un tel rythme de dizaines de commits par mois pendant des années, ça peut revenir dans la danse).
Bon apparemment cinelerra est aussi développé par une société, Heroine Virtual LTD, mais bon la page de download indique tout de même « Downloads have no support or warranty and are not community approved. Linux derivatives are so incompatible, don't be surprised if the source code requires some tweeks and the binary doesn't work. » ce qui donne pas confiance dans leur qualité de développement (chez moi avec les bons outils, y a pas d'incompatibilités extraordinaires entre les diverses distrib GNU/Linux. Qu'on dise "attention testé seulement sur…" ok, mais là c'est bizarre comme tournure). Mais bon on peut s'attendre dans ce cas à ce que le logiciel s'améliore?.. À voir… Dans tous les cas, le problème de manque d'ouverture et d'absence de dépôt de source accessible au public rend ce développement plus hasardeux (ils font juste des sorties).
Et on peut clairement lire que ce n'est plus la priorité de cette boîte. Ils l'ont présenté à quelques "shows" entre 2000 et 2004, puis plus rien, d'après leur site. Je parle même pas du copyright de bas-de-page: «(C) 2013 Unemployed, flat broke Programmers»
Je constate aussi qu'il y a deux site web pour la version communautaire: le site originel cinelerra.org, qu'ils ont et un nouveau site web: http://cinelerra-cv.org/
Apparemment cinelerra.org n'a pas été renouvelé et quelqu'un s'en est emparé. Mais de façon amusante, ça parle toujours de Cinelerra, mais seulement de la version pro, j'ai l'impression (est-ce la société Heroine Virtual qui a racheté? Le whois ne dit pas). Et il n'y a rien pour télécharger (par contre, on nous demande notre email pour un "download update").
Enfin bon, tout ça m'a l'air bien compliqué. Peut-être cinelerra mérite-t-il de nouveaux tests? Mais j'espère vraiment qu'ils ont amélioré la stabilité car c'est vraiment là où ça pêchait.
Tout ça pour dire que cela ne m'étonne pas qu'on ne considère plus cinelerra dans la course. Blender aussi à l'époque les gens disaient qu'ils avaient un UI dur à prendre en main, etc. Ben ils ont bossé comme des dingues pour s'imposer (et changer ce qu'il fallait) et ils sont loin de cette époque maintenant. Cinelerra aurait pu faire la même chose, mais j'ai l'impression que cela fait longtemps qu'ils se sont laissé aller.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ok.
Je serais personnellement pour prévenir l'association LinuQ, et retirer le lien de linuxfr (éventuellement temporairement le temps qu'ils trouvent le problème) avec un petit message expliquant pourquoi. Je doute qu'un lien en première page de linuxfr qui redirige sur un site de cul soit vraiment idéal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Uh! J'ai eu exactement la même page que toi à l'instant (sauf que la mienne, y avait pas de culotte)! Mais si je réessaie immédiatement après, ça me donne dorénavant la bonne page. Y a un problème quelque part là, le système de redirection de linuxfr n'aurait-il pas été corrompu et redirigerait de temps en temps vers ce site? Ou alors c'est le site du lien lui-même qui aurait ce problème. Mais dans les deux cas, je doute que ce soit normal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sur testing c'est ce que tu as (les paquets n'entrent jamais directement dans testing, ils entrent sur sid (= unstable) puis après une semaine arrivent dans testing.
Ah ok. On entends tout de même pas mal d'histoires terribles sur les problèmes rencontrés en utilisant Debian testing. C'est pour cela que je faisais cette distinction.
Je me demande d'ailleurs à quel point on peut tester un build en une seule semaine. Dans Gentoo, je sais pas combien de temps les paquets restaient "unstable", mais cela pouvait durer longtemps, surtout pour les petites applications pas très utilisées (qui parfois restent même indéfiniment "unstable" si le peu d'utilisateurs fait que personne ne remonte rien). Évidemment les gros logiciels connus eux passent stable bien plus rapidement (mais en combien de temps? Une semaine me paraît tout de même un chouille court, non? Quoique si c'est Firefox, les retours doivent être par dizaines au bout de quelques jours…).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ah ok, bon ben voilà. S'ils inventent encore d'autres trucs pour contourner le fait qu'ils prennent pas de fichiers… C'est pourtant simple les fichiers. Un concept que tout le monde comprend parmi les développeurs, non? Pourquoi remplacer cela par un service de copier-coller en ligne?
bla bla mailing list
La plupart des mailing-list accepte les mails des gens hors-ml (souvent après modération dans 99% du temps). Donc ce n'est pas un grave problème. D'autant plus que si c'est un simple "bug + patch", le bugtracker est plus approprié (et celui-ci ne spam pas grand chose en général).
Effectivement ça peut déranger d'envoyer ton patch sur la mailing list, mais donc uniquement parce que c'est pas vraiment l'endroit (c'est dur de faire du suivi dans un contexte de flot d'emails. On perdrait les patchs!). D'ailleurs certains projets filtrent même les fichiers des emails (pour éviter les gens qui mettent d'énormes fichiers, ou bien les fichiers à but malveillant, etc.). Sur les mailing lists GIMP par exemple, ton email arriverait sans le patch. Tout ça pour dire que c'est vraiment pas l'endroit.
Ensuite oui, je suis d'accord que ça veut dire devoir s'inscrire encore à un énième site pour déposer son rapport de bug. Et ça c'est chiant. C'est un problème qui existe depuis l'aube de l'internet. Mais centraliser tout dans les mains d'une unique entreprise n'est pas, et ne sera jamais selon moi, la solution (même si c'est effectivement celle que poussent comme par hasard toutes les entreprises, entre les "connect by Facebook" et autres trucs du même acabit). Les solutions acceptables seraient plus dans l'optique openid, avec le succès (peu) qu'on connaît (mérité peut-être car je ne trouve pas la solution technique si adéquate). En attendant, faut faire avec. Je préfère tout de même faire un énième compte sur le site d'un projet auquel j'ai décidé de faire confiance (sinon je leur enverrais pas de patch probablement), plutôt que pousser l'ensemble des développeurs du Libre à s'enfermer dans un unique "réseau social développeur", propriétaire et sous le contrôle d'une unique société.
Note que j'ai rien contre les sociétés qui font cela. C'est une très bonne idée et un plutôt ok service dans le cas de github. Je suis juste pour la diversité, et je refuse de mettre tous mes œufs dans un même panier. Donc je ne ferai jamais la promotion publique d'un service en particulier. Enfin si, je peux dire "c'est bien, ça marche" (c'est le cas de github: "c'est bien, ça marche", mais ça a vraiment rien d'une révolution et leur workflow est tordu et mal-foutu par endroit. Cf. cette discussion), si on me demande, mais ça s'arrête là. :-)
Mais il illustre un autre avantage (mineur je le reconnais) de cette incitation au fork : même si un jour le dev initial décide (sur un coup de tête, problème légal,…) de tout supprimer, le code est toujours là. Avantage que n’auront pas les petits projets sur des trucs genre sourceforge.
Euh, par définition, tous les gens qui ont le dépôt git ont la même chose, pas besoin de github …
Tout pareil: c'est le principe de git. Je vois pas le rapport avec le fait que ce soit sous github, sourceforge, auto-hébergé ou autre. À te lire, on dirait que github a inventé git!
[Note: pour être clair, je réponds à Moonz, pas à Zul. Mais comme je suis globalement d'accord avec Zul, j'ai pris son message comme base.]
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Moi, quand je dis "rolling release", j'entends "stable". Je sais pas comment c'est sur Arch, mais en lisant la description plus haut, cela m'a l'air similaire à ce que j'avais sur Gentoo: des paquets stables et déjà testés. Mon expérience Gentoo fut vraiment très satisfaisante. C'était très stable. Une mise à jour ne pêtait pas tout.
Ça ne dit pas qu'il ne peut y avoir un problème innattendu qui pête ta machine, mais comme pour toute autre distribution stable: ce serait une erreur passée entre les mailles du filet, et à corriger rapidement, non la norme.
Debian testing au contraire, c'est de l'expérimental (d'où le nom "testing"). Les utilisateurs sont des contributeurs qui acceptent d'être les premiers à essayer des paquets non-testés, pour ensuite remonter les problèmes, avec tous les risques que cela comprend. Ensuite c'est peut-être à considérer "rolling release" aussi, mais c'est juste pour dire que c'est pas du tout la même catégorie. C'est pas fait pour être sur ta machine principale (enfin tu peux, mais à tes risques et périls). Gentoo par contre si (note que sous Gentoo aussi, on peut récupérer les paquets non-testés si on veut, et on se retrouverait alors dans le cas Debian testing. Ce qui est super bien ceci dit, c'est la gestion fine des tests: un flag au niveau des paquets. Donc on peut télécharger certains paquets en tests, et le reste en stable par exemple).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Ce qui t'embète sans doute, c'est de simplifier la vie de mainteneur (sur GitHub, il accepte ou pas ton patch, tout est prêt, pas à s'embeter, ton nom tout ça tout comme il faut, la discussion a eu lieu ailleurs).
La discussion, qu'elle ait lieu dans une mailing list, sur un bugtracker ou sur github, je vois pas la différence.
Ensuite j'ose espérer que les mainteneurs github testent les patchs sur leur dépôt local, et se contentent pas de croire sur parole un inconnu. Quand ça vient d'un contributeur habituel ou que c'est un patch très mineur (changement de string ou autre), ok, se contenter de regarder la syntaxe peut suffire. Mais sinon, même un patch d'une ligne peut casser des choses, et la plupart du temps, ne pas tester n'est pas conseillé.
Donc déjà à partir de là, faut quitter son navigateur et appliquer le patch. Une fois fait, testé et approuvé, y a juste à git push. Avec github, il faudrait revenir dans son navigateur pour faire le changement.
Ensuite quand tu me dis "pas à s'embeter, ton nom tout ça tout comme il faut", j'ai tendance à penser que tu n'as jamais fait ou reçu de patch git, ou alors je comprends pas ce que tu veux dire.
Quand quelqu'un m'envoie un patch git, je le git am, et j'ai un git log parfaitement "comme il faut", avec le nom de l'auteur et son email, la date de son commit (pas seulement la date à laquelle j'ai appliqué le patch, qui elle correspond au CommitDate), et finalement le message de commit qu'il avait déjà préparé. "Pas à s'embêter", comme tu dis. Une fois bien testé et approuvé, j'ai juste à git push, et c'est fini. On gère un patch envoyé en deux commandes (avec les commandes de build, etc. et tests entre-deux normalement, mais ça, c'est pareil quelque soit le workflow si on fait les choses consciencieusement), en restant dans sa console.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
ça me paraît normal que ce sot le mainteneur qui définisse le workflow qu’il préfère — après tout c’est lui qui a à gérer des patchs tous les jours.
Ça je suis d'accord. Je ne me suis d'ailleurs jamais plaint à un mainteneur d'un projet sur github directement, et je suis le processus demandé douloureusement mais silencieusement. Je répondais juste à la remarque générale comme quoi tu trouvais ce nouveau workflow git (car non ce n'est pas le workflow prévu pour git, j'y reviens plus bas) révolutionnaire.
Gist est fait pour ce genre de choses.
Tututut. Demandons par exemple au développeur originel de git, Linus Torvalds: https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Donc non clairement, ce n'est pas le workflow prévu par git.
Ensuite il y a des logiques de workflow différentes, et chacun est libre, encore une fois. Je n'arrive pas avec mes gros sabots voir un mainteneur d'un projet et lui dire que son workflow pue et qu'il devrait changer. Mais lire que git est fait pour ce workflow, ben non clairement. Là faut pas abuser, surtout quand l'auteur de git a déjà dit maintes fois que c'est pas le cas et refuse tout "pull request" passant par le système complètement cassé de github.
Comme dit juste au dessus, c'est pas vrai. Cette façon de faire est une spécificité github. Mais effectivement quand on reste dans la "communauté" github de gens qui ne connaissent que cette façon de faire, on a l'impression que tout le monde aime cela. Ben moi en dehors de cette communauté, je rencontre aussi plein de gens qui n'aiment pas.
Je fais des branches à part pour à peu près tout (je suis un grand partisan d'un workflow par "branche de fonctionnalité"), mais il y a plein de cas pour lesquels ne pas avoir 2 branches séparées est valable, ne serait-ce que pour 2 patchs mineurs sans aucun rapport, et sur des fichiers totalement différents (ils ne peuvent pas interférer). En gros faut quand même distinguer une branche de fonctionnalité d'un bug fix de quelques lignes.
Ensuite, dans mon précédent message, je parlais pas de cherry-pick (j'ai pas compris pourquoi tu m'en parlais). On ne fait pas de cherry-pick tout le temps, effectivement ce serait très lourd. Non on git am (on peut le git apply d'abord s'il s'agit d'un patch compliqué et qu'on veut le tester en profondeur sans avoir peur de le pousser par erreur) un patch proprement formatté par github, avec message, auteur et tout. On teste, puis on pousse.
Pour des petits contributeurs, il est normal de faire les choses par fichiers. Rends toi compte que le système à la github est en train de pousser les gens à mettre en ligne un dépôt public, pour des fois un patch d'une ligne, et qu'ils ne reviendront jamais sur ce dépôt? C'est le marteau pour écraser la mouche. Github simplifie cela en rendant cette partie facile, mais la contrepartie c'est qu'on se retrouve à avoir des dizaines de clones publiées pour plein de projets (les fameux "forks") qui sont juste des zombies laissés à l'abandon.
Donc non le coup de merger des branches, c'est bien entre contributeurs importants, ceux pour qui effectivement cela devient plus pratique d'avoir une branche publique. Tu penses que combien de personnes ont leur propre branche sur les projets énormes comme linux? Les divers mainteneurs, et quelques contributeurs très prolifiques. Et encore souvent, eux se feront des branches sur un même dépôt, pas leur propre dépôt!
Et tu penses que faire son propre dépôt devrait être la norme, même pour les contributeurs mineurs? C'est de la folie. C'est pas pour rien que git send-email a été inventé. C'est parce que contribuer par patch est la norme des petits contributeurs, les branches publiques, on les laisse aux gros contributeurs.
Encore une fois, de la littérature par l'auteur de git: https://www.kernel.org/doc/Documentation/SubmittingPatches
Comme tu le vois, les pull requests sont un seul point, le dernier, pour envoyer des patchs (point 16 de la section 1). Tout le reste se concentre sur le formattage de patch en fichier à envoyer par email (note que lu comme ça, ça a l'air compliqué, mais je pense que c'est parce que c'est un vieux texte. De nos jours, quasi tout ce blabla se fait en une ligne: git format-patch origin/master, "master" à remplacer par une autre branche selon la branche qui sert réellement d'origine). Parce que franchement faire un dépôt public pour un patch, c'est vraiment en faire un peu trop.
Je pense que github a même cet effet pervers d'empêcher les gens à apprendre à connaître vraiment git et son fonctionnement. On rencontre régulièrement des gens qui veulent qu'on fasse tout sur github, mais c'est uniquement parce qu'il ne connaissent que cela et qu'ils se rendent compte qu'il ne savent pas utiliser git en dehors des boutons du navigateur (sérieusement, le fait que tu me répondes "cherry-pick" à un "format-patch" par exemple me fait des doutes quant à ta compréhension de comment marchent les patchs formattés par git; le fait que tu me parles de "branches" alors que github fait même carrêment des clones de partout aussi).
c’est vachement plus simple pour rebase (rebase sur master c’est une très très mauvaise idée)
Oulaaaaah! C'est une très mauvaise idée… sur toutes les branches publiques! Encore une fois, il y a plusieurs logiques. Certains vont effectivement rebaser des branches de fonctionnalités, même publiques (il y a effectivement 2 écoles majeures: les rebaseurs fous, et les mergeurs fous. Curieusement tu m'as l'air d'être un mix des deux…). Mais c'est loin de faire l'unanimité. Encore une fois, tu dis ça à Linus, il t'insultera allégrement. Sa logique, qui est le workflow du projet du noyau linux, et donc probablement très répandue, est de ne jamais rebaser une branche de fonctionnalité publique. C'est exactement la même chose que master, dont tu parlais plus bas. Une branche publique, quelle qu'elle soit, se retrouve copiée dans les dépôts locaux de tous ceux qui ont cloné le dépôt. Et il est tout à fait possible que quelqu'un ait commencé à bosser dessus. Rebaser dans ce cas fout le bordel (oblige de créer une série de patchs et/ou stasher pour ce qui n'est pas déjà sous la forme de commits, supprimer sa branche locale, la recréer, et ré-appliquer tous ses propres patchs. Très lourd). En outre tu casses un historique de hash de commit, ce qui peut créer des problèmes de discussions. À partir du moment où une branche a été rendue publique, on a pu discuter certains commits sur une mailing-list/chat/tracker/etc. Et on rend tout nommage de commit inutile si on se permet de renommer (par rebase) à tout va.
Heu… tu vas sur https://github.com/joincamp/flp.mobi/ par exemple, et juste en dessous du nom tu as « forked from fmap/flp.mobi ». Tu vas sur https://github.com/joincamp/flp.mobi/network/members et tu as le graphe des forks, avec l’upstream en tant que racine de l’arbre. Le seul truc un peu mal fait c’est que c’est pas clair du tout pour un mainteneur de dire « je passe la maintenance à x » (je sais même pas si c’est possible autrement que par un README en fait). Mais c’est pas tellement dramatique dans la mesure ou tu peux autoriser celui à qui tu passes le lead à push dans ton dépot :)
Mouais je comprendrais jamais comment on peut trouver sain cette nouvelle mode de tout forker. Comme tu le confirmes, rien n'est clair. Et je suis désolé, même le "forked from" est loin d'être la première chose que tu vois en arrivant sur la page (encore une fois, pour ceux qui passent leur temps dans github, c'est peut-être évident, mais pour les autres…).
Avec ton exemple, je suis en effet totalement dans le flou. Y a une vingtaine de forks, la plupart quasi les mêmes, mais parfois avec une petite différence, rarement mais parfois avec beaucoup de différences. Et ironiquement, le dépôt original a été vidé (et le README ne passe pas la maintenance justement). Donc si t'es un dév, ou un utilisateur, tu fais quoi? Tu testes les 21 forks un à un pour voir ce qui a changé?
Franchement ce système de fork, c'est plus du réseau social qu'autre chose (plein de gens me forkent! Oh oui allez y, forkez moi! ;-p), mais je trouve cela anti-productif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
Sérieux, je suis pas d'accord. Github marche bien quand on est toujours dedans, et qu'on ne bosse qu'avec ça. C'est d'ailleurs le but de la plateforme: enfermer les développeurs à l'intérieur et faire en sorte qu'ils n'en sortent pas.
J'ai essayé l'autre jour de patcher des bugs dans un projet hébergé par github. Au début, je fais un rapport de bug, me disant que je vais y uploader mon patch (correctement formaté avec git format-patch origin/master). Ah pas possible. On peut seulement uploader des images. Sérieux?!
Je me suis retrouvé à devoir "forker" le projet (sur le site web seulement), modifier mon .git/config pour ajouter mon remote, pousser mes commits, retourner sur le site, et finalement faire une demande de pull (on peut même pas faire une demande par commits, mais pour tous les commits d'une branche donné. Uh?!). Sérieux, on trouve ça plus simple?!? En plus si je veux suivre le projet, je me retrouve à devoir gérer 2 remotes depuis mon dépôt local. Note que c'est courant voire normal de gérer plusieurs remotes si t'es un mainteneur d'un gros projet, mais c'est lourd pour un contributeur intermittent (qui envoie un patch tous les 36 du mois) car on peut se retrouver vite à s'emmêler les pinceaux. Avoir des branches locales et se baser sur un seul remote est bien plus facile.
Bien sûr la raison est de te pousser à gérer tout cela dans ton navigateur, sur le site web, puisque leur UI a un workflow adapté à ces logiques incongrues. Mais franchement je préfère de loin gérer le plus de truc possible dans ma console.
Je parle même pas de la sémantique. C'est pas un fork que je veux faire! Je veux juste patcher un projet, pas le forker. C'est d'ailleurs terrible pour les petits projets: combien de fois (des dizaines!) je me suis retrouvé sur un projet github à me demander s'il s'agit de l'upstream ou non. Pour des petits projets, un moteur de recherche peut répondre plusieurs pages github et la première n'est régulièrement pas l'upstream.
Non, moi si je veux publier un projet, je reste sur tuxfamily ou autre petit hébergeur. Au moins, ils essaient pas de se faire passer pour du réseau social.
Et je dis tout ça, mais j'ai pas mal utilisé Github, quotidiennement et des milliers de commits lorsque je bossais pour une startup qui l'utilisait. Ça marche très bien tant qu'on reste dedans et qu'on s'adapte à leur logique bizarre de fork, y a pas à dire. Mais c'est loin d'être la meilleure logique de contribution.
Sinon pour répondre, moi aussi, c'est pour moi: je veux réparer des logiciels ou avoir des fonctionnalités, je les code. J'ai appris à ne plus me reposer sur et attendre les autres, mais à faire les choses moi-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
C'est vrai, y a de quoi se poser la question. D'ailleurs quelque chose d'autre m'a intrigué: pour les utilisations "routinières" dont tu parles (signer, déchiffrer, authentifier), s'il n'y avait pas la carte, les logiciels de cryptage (GnuPG en tête donc) tirerait profit de /dev/(u?)random, non? Donc finalement, ton programme ne pourrait-il pas tout simplement remplacer Scdaemon de manière transparente? GnuPG ne communiquerait plus directement avec la carte, mais en cherchant de l'aléa dans les /dev/(u?)random, il utiliserait indirectement la carte en fait, sans même avoir à le savoir.
Ou alors la carte a d'autres fonctionnalités et son rôle n'est pas uniquement de produire de l'aléa rapidement. Y a un processeur dédié pour accélérer des calculs de crypto aussi, peut-être?
Comme je le disais, je connais rien à ces cartes, donc ces questions sont peut-être un peu ridicules, mais bon. C'est bien pour ça qu'on demande un article supplémentaire dessus. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Une librairie pour qui?
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Sortie de Blueprint v0.1. Évalué à 4.
Donc une bibliothèque "bullshit-ready" tu veux dire?
Non je déconne, j'ai juste lu cette phrase d'accroche et ça m'a fait réagir au quart de tour. Je sais pas, je suis en forme aujourd'hui! :P
Pour rester dans le sujet, ça fait des jolis graphiques en tous cas. :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# OpenData en papier
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Le prix des carburants enfin en OpenData. Évalué à 10.
Salut,
Le vocable y est: "met à disposition de manière libre et gratuite", "OpenData", "Données publiques", etc.
Ça a l'air cool, néanmoins j'ai cherché des détails plus précis que ce discours marketing. Je vois un lien "Condition de réutilisation des données" en bas, je le clique. Et là ça dit: « La réutilisation des données […] n'est autorisée qu'après avoir obtenu du ministère de l'économie et des finances une licence de réutilisation d'informations publiques contenues dans la base de données du site du prix des carburants. »
Déjà ça commence mal, je suis le lien vers l'arrêté du 28 février 2013 qui définit les conditions.
Déjà, aparté, je note que bien qu'il s'agisse clairement d'un document informatique (enfin à part s'ils utilisent encore des machines à écrire au gouvernement), ils ne savent toujours pas utiliser leurs ordis. Ils mettent en ligne une version imprimée-scannée! Si encore y avait eu une raison (papier signé, ou annoté ou quoi. Non rien. Juste ils savent pas qu'on peut "imprimer" directement dans un fichier). Fin de l'aparté, mais c'est juste que j'avais voulu faire un copier-coller de la partie intéressante, je peux même pas (je dis pas, c'est peut-être aussi sur Legifrance, mais quand même! Dans ce cas là, ils donnent un lien vers le texte utilisable. Pour un site sur l'OpenData, ça le fout mal).
Donc en gros, sur le papier que je peux même pas copier-coller, ça dit que pour réutiliser sur OSM, c'est considéré comme réutilisation commerciale (« en vue de l'élaboration d'un […] service destiné à être mis à disposition de tiers à titre gratuit ou onéreux »). Ok on sent venir la facture.
Pire cela pourrait éventuellement être classé comme utilisation commerciale "intermédiaire". C'est pas clair si on doit considérer OSM comme « destiné [NDR: gras de moi] à être mis à disposition, à titre gracieux ou payant, à d'autres opérateurs économiques pour une réutilisation commerciale », mais c'est clairement une des utilisations.
Bon bah si on considère cela comme utilisation commerciale finale, c'est 5000 EUR par an les 2 premières années, puis 10.000 par an. Si on est intermédiaire, c'est 38.500 par an.
Bon voilà, c'est bien pour les particuliers qui peuvent aller direct sur ce site gratos, peut-être bien aussi pour Google et consort, pour qui c'est une source d'info fiable (et 38.500 par an, c'est une pichenette pour eux), mais c'est pas encore cela pour OSM. Déjà financièrement, mais même s'ils avaient les sous, ils ne peuvent mélanger ces données à leurs données en CC by-sa.
Quant à l'OpenData? On repassera. C'est un peu des guignols, ou alors plutôt ils nous prennent pour des cons.
Pourtant je me dis que si c'est un problème de financer les caisses de l'état, ils pourraient faire de la double licence: CC by-sa + une licence proprio chère. Une boîte comme Google ne peut mélanger du CC by-sa à ses données, et donc paieraient, car ils ne peuvent se permettre (voire n'ont pas le droit puisqu'ils ont eux-même des accords) de licencier leur propre données géographiques ainsi (et s'ils le faisaient, ben ce serait un bien pour le monde!). Tous ceux qui font du CC by-sa comme OSM pourraient y accéder. C'est pourtant pas trop dur de trouver des solutions raisonnables pour avoir des données publiques réelles, pour le bien du peuple, tout en remplissant un peu les caisses.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 3.
Y a pas beaucoup de Jehan sur Terre. J'en ai déjà rencontré une fois y a des années sur le web (un vrai Jehan, parce qu'y aussi ceux dont c'est juste un pseudo; comme la Jehane qui venait sur linuxfr, il me semble lui avoir demandé un jour, et elle m'avait dit que c'était un pseudo. Enfin il me semble), mais j'attends encore d'en rencontrer un en face de moi (sauf celui dans mon mirroir, mais il m'énerve à me copier, celui-là!).
Donc oui.
Ben je m'y suis intéressé y a plus d'un an quand j'en ai entendu parler pour la première fois, et je suis donc rentré dans l'équipe comme développeur software. Dans les faits cependant, je regrette presque car à part ajouter quelques petites fonctionnalités sur des scripts que certains cinéastes de l'équipe utilisent pour traiter leurs rushes, et des discussions (sur notamment le choix d'un NLE comme "référence" pour démontrer un workflow Libre complet), je ne me suis jamais donné le temps d'en faire plus. C'est un choix, parce qu'il faut bien faire des priorités (mes projets persos), et ce n'est pas le point que je regrette. Je ne regrette pas non plus de m'être approché du projet car je le trouve toujours aussi cool (j'ai d'ailleurs réservé ma caméra par le crowdfunding). Ce que je regrette, c'est que ça fait un peu "promesse pas tenu", quand on se propose à contribuer et qu'au final (oups), on prend pas le temps.
Mais personne n'en est mort. ;-)
Enfin bon, je suis toujours dans la mailing list "team", et je donne mon avis de temps en temps sur les sujets ou je peux (généraux ou software). Mais dernièrement ça se limite là. Ça me permet tout de même d'avoir une vue de première main sur les dernières nouvelles et les choix et décisions pris. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 3.
Ok. Bon je suis autant dans le flou que toi côté matériel. Donc peut-être que je dis de grosses conneries, mais justement en voyant les diverses simulations 3D (par exemple sur la page de financement), ainsi que les photos de l'Alpha dans le blog (voir: https://www.apertus.org/axiom-beta-in-the-lab-axiom-alpha-in-the-field-article-2014), ben j'avais justement l'impression que la caméra pourrait être très petite, même plus petite que la caméra autonome de ta photo.
Alors bien sûr, faut imaginer une boîte autour de ce prototype à nu, ça aura pas du tout cette forme, etc. Mais on voit que c'est pas énorme quand même.
J'ai l'impression que ce qui devrait prendre le plus de place dans la caméra sera les objectifs (quand on voit les objectifs de fou qu'ils utilisent dans le cinéma), mais bon là, y a rien à faire, c'est le cas toujours, et surtout quelqu'un qui veut juste une petite caméra portable pour filmer un entretien pourra juste mettre un petit objectif et il a sa cam transportable.
Enfin j'espère! Encore une fois, je me suis pas occupé du hardware du tout dans ce projet! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 2.
J'ai pas trop compris pourquoi tu dis cela. J'avais un peu cette peur où tout début quand le projet Apertus a commencé à faire parler de lui et que j'ai regardé ce qui avait été fait du côté de Elphel. Mais depuis les choses ont énormément évolué et la description est assez claire.
Alors oui, de base, y a juste une boîte. Il manque un viseur/écran LCD et des contrôles (bouton, ou sensitivité à la pression, etc.). Pour cela, en attendant, on peut connecter une machine en ethernet/wifi/usb/autre, et tu vas me dire en effet, c'est moyen transportable. Sauf que maintenant on fait des machines super puissantes et super petites. Et je dirais même plus: la plupart des gens ont désormais un ordi dans leur poche (smartphone). Pouvoir contrôler une petite caméra (et avoir une prévisualisation) à distance avec son smartphone, certains te diront que c'est au contraire bien plus transportable qu'un écran LCD et des boutons sur la boîte.
Note que la version prototype actuelle est un serveur web, donc n'importe quel smartphone, sans logiciel particulier autre qu'un navigateur, peut se connecter à la caméra, modifier les divers paramètres (le prototype Alpha propose quelques boutons pour contrôler la vitesse d'ouverture, les profiles de couleur, quelques autre paramètres, et afficher quelques données genre histogramme temps réel, courbes de couleur…). Ça n'empêchera pas d'avoir des logiciels plus sophistiqués plus tard qui permettront plus. Mais déjà y a une base standard et simple.
Ensuite reste le problème de l'enregistrement. Les capacités de base (interne en microSD) sont certes très limitées en vitesse comme en espace. Tu peux aussi connecter un ordi à distance en wifi (ou en ethernet pour aller plus vite), et j'admets que ce n'est pas le plus "transportable" (quoique un petit ordi dans le sac à dos, ça reste léger et peu encombrant). Si tu as des besoins élevés (raw 4K ou FullHD, probablement pour la plupart qui veulent cette caméra), tu voudras connecter une interface d'enregistrement externe. Et je suis persuadé que le module d'enregistrement HDMI sera l'un des premiers modules à sortir quasi en même temps que la caméra (d'ailleurs il est cité dans la page de financement).
Donc au final, la caméra + l'objectif (comme toute caméra de ciné) + le module d'enregistrement + module alimentation + écran LCD, franchement ce sera pas gros. N'importe quelle caméra que je vois sur un tournage serait au moins aussi grosse (en générale elle sont toutes très grosses sur les tournages si vous avez déjà vu).
Et y aurait moyen de la faire tout de même passer dans des situations très "transportées" au contraire. Un voyage en voiture? Juste la base + objectif dehors (sur le capot ou le toit du véhicule par exemple), relié à un petit ordi pour visualiser et contrôler depuis l'intérieur. On doit même pouvoir l'installer sur une moto avec ce genre de système (les caméras de ciné classiques sur une moto, c'est plus casse-gueule). Même à pied, y a des moyens d'arranger justement pour porter du poids dans le sac et ne porter que la partie visée à la main.
Enfin voilà, je pense que ça se défend au niveau transportabilité. Mais peut-être veux-tu étayer ta pensée, j'ai peut-être loupé quelque chose…
Ou alors quand tu dis "transportable", tu parles des mini-caméras genre gopro? AXIOM n'a jamais aspiré à ce marché là. Le but a toujours été de faire une caméra pour le cinéma.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: ...
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal int *(*(*foo[])(int))(float*);. Évalué à 10. Dernière modification le 13 septembre 2014 à 15:47.
Je sais pas si c'est une vraie question ou rhétorique (histoire de signaler un cas où la syntaxe est en effet peu claire), mais au cas où, je vais y répondre. :-)
iest un pointeur sur entier,jest un entier. C'est je pense la raison pour laquelle beaucoup de projets vont plutôt écrire l'étoile à côté de la variable, non à côté du type, pour qu'on voit bien à quelle variable cela s'associe:Enfin si tu voulais avoir 2 pointeurs, tu écrirais:
Note que je n'écris dorénavant plus jamais de déclaration de cette sorte, car je trouve en effet cela abscons, et je me posais aussi la question à une époque (jusqu'à ce qu'un jour, je teste). Maintenant je déclare une variable par ligne, même si c'est le même type. Je trouve cela plus clair de cette façons. Au moins, plus de question. :-)
Ça a l'air d'un cas différent, mais c'est en fait très similaire à ce que tu as au dessus (en gros), c'est à dire que tu dois associer le '*' avec ce qu'il y a après.
const char *p-> tu as d'un côtéconst char, de l'autrep. Donc ça signifie que p est un pointeur sur const char. Le pointeur lui-même n'est pas constant (tu peux changer la valeur depautant que tu veux). Mais la valeur pointée parpelle ne peut pas changer (tu peux cependant faire repointer vers une autre valeur différente, ce qui a un résultat similaire).char * const p-> d'un côtéchar, de l'autreconst p. Cela signifie donc que p est un pointeur sur un char (variable). Tu peux changer cette valeur pointée (le char) autant que tu veux, par contre, tu ne peux plus jamais changer le pointeur p lui-même après son initialisation.C'est compliqué, mais faut s'y retrouver avec des associations de ce genre.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 4.
La différence? C'est pas de l'OpenHardware. Alors oui le prix affiché pour ces caméras semble moins cher que le prix attendu pour AXIOM. Mais déjà ce prix annoncé par Apertus n'est pas vraiment décisif, et a été pris large en considérant les prix marché. Le but étant que le prix final ne devrait être qu'inférieur (bonne nouvelle!), identique au pire, mais surtout pas supérieur. Je cite:
Donc il y a de bonnes chances que le prix de production soit en réalité bien en dessous. Cela dépendra du volume de production (et comme la campagne a du succès, il y a de bonnes chances que le volume de prod soit important dès les premiers modèles, ou que les usines fassent de bons prix car ils pourraient y voir du bon potentiel commercial sur le long terme).
Rappelez-vous. Les premières annonces du projet indiquaient un vague "moins de 10,000 EUR". Maintenant on est dans les 1900/2300 EUR pour le prix de production, et le double (soit ~ 3800/4600 EUR) pour le prix de vente normal. Et ce prix a encore de bonnes chances de baisser (peut-être dès les premières productions, ou les suivantes).
Mais comme je disais, ce n'est pas le point important pour autant. OpenHardware l'est. Qu'est-ce que cela signifie:
1/ customizable: à peine annoncé, deux capteurs sont proposés. Selon les demandes (ou même des contributions communautaires), d'autres capteurs pourront être proposés. Y a deux jours par exemple, quelqu'un nous demandait si on considérait CMV20000 aussi (mais l'interface est complètement différente, donc la réponse fut qu'il y aurait du développement spécifique à faire, et aussi que le prix d'achat est quasi double de celui du CMV12000, donc ça monterait bien le prix du tout). Mais ça se limite pas au capteur. Tout élément pourrait être modifiable, et les modules attachables peuvent être développés (et vendus!) par tout un chacun, pour tout type de besoin.
Ça veut dire qu'on peut s'attendre à des modèles plus chers mais de bien meilleure qualité, mais aussi des modèles moins cher si y a la demande (mais en voyant le succès des modèles avec de meilleures composants dans le financement, j'ai l'impression que les gens préfèrent payer plus pour mieux que l'inverse).
Les autres caméras? Y a pas de choix. Il peut y avoir des options, mais même si y en avait des dizaines, ce serait toujours limité. Une seule entreprise est au volant, et ils ont un contrôle ferme sur le produit. Je doute même que les utilisateurs puissent ouvrir la bête (enfin techniquement on peut toujours, mais au niveau garantie, cela la cassera sûrement aux yeux de l'entreprise).
2/ réparable: tu casses ta petite caméra commerciale à 2000 EUR, seule l'entreprise vendeuse est à même de réparer, et il y a de bonnes chances que le devis qu'ils te feront sera quasi aussi gros que le prix du nouveau modèle (tu te rends compte, t'as le modèle d'y a un an! C'est has-been!). Bon bah on achète le nouveau modèle alors, hein? Qui ne connaît pas cela? Qui n'a jamais vécu cela avec d'autres produits? C'est le business modèle de la plupart des produits électroniques "pas cher" de nos jours. Certains appellent cela l'obsolescence programmée.
Tu casses ton AXIOM? C'est fait pour être réparé, donc déjà tu peux être assuré qu'ils ne joueront pas le jeu de te faire des devis hors de prix pour juste changer une résistance qui a grillé (parce que t'y connais rien). Et quoi, tu veux pas attendre? Ben t'as les plans! Soit tu t'y connais et tu peux réparer toi-même aussi, soit par exemple, tu peux aller à l'électronicien du coin. Peut-être même que tu as quelqu'un dans ton équipe de tournage qui s'y connaît suffisamment en électro (un chef op, ou que sais-je).
En gros, même si Apertus décidait soudain de devenir un vilain et de te faire payer des sommes folles pour changer ta résistance, tu as toujours plein d'alternatives viables.
3/ mettable à jour (donc jamais obsolète): tu veux un nouveau modèle? Qu'à cela ne tienne! Envoie ta caméra et on te l'installe (ou encore une fois, installe toi même; ou achète le composant et paye un électronicien!). Pourquoi racheter tout un appareil et polluer/gâcher/jeter toute ton ancienne caméra, encore parfaitement fonctionnelle, quand le nouveau modèle est globalement la même chose avec un ou deux composants différents, et le circuit imprimé mis à jour?
Mise à jour moins chère, moins de déchets, plus économique et écologique donc. L'OpenHardware c'est aussi ça. Apertus a déjà même prévu la mise à jour vers AXIOM Gamma, en annonçant que les financeurs auraient là encore un prix d'ami.
On parle bien de mise à jour, pas de "prix d'ami pour acheter en plus la version gamma". Non ce sera: "t'envoies ta beta, on ouvre la bête, et on la transforme en gamma, et tadaaaaa"!
C'est un procédé classique en OpenHardware, et j'ai déjà vu similaire sur d'autres produits pour la mise à jour. En gros, on n'essaie plus de cacher "comment ça marche". La plupart des produits commerciaux sont vendus comme des sortes de "bloc" tout-en-un, une boite noire indissociable de son contenu. Tu veux mieux? Tu changes le tout et tu revends (bien moins cher que l'achat) ou tu jettes.
Avec l'OpenHardware, on fait prendre conscience aux gens que leurs machines ne sont pas des boites magiques dont on ne comprends pas le fonctionnement et la mécanique interne. Ce sont bien des machines créées de multiples éléments associés les uns aux autres, réparables, changeables indépendamment du reste, et mettables à jour. Alors tu n'as pas nécessairement à être électronicien et à comprendre le détail pour comprendre cela. De même que sans être mécanicien, je sais que mon véhicule est composé de pleins de pièces que je peux changer individuellement, et que je n'ai pas juste à changer de voiture si elle se met à avoir des problèmes (quoique même là, à des prix bien plus élevés pourtant, les entreprises essaient de plus en plus de jouer ce jeu là de la "boite noire magique", et pas mal d'acheteurs avec les moyens jouent le jeu de racheter tous les 2/3 ans pour un rien).
C'est bien plus sain. C'est aussi plus juste envers les acheteurs et ça prend moins les gens pour des cons. Enfin même si cela pourrait sembler plus cher à l'achat, si c'est un produit dont on a vraiment besoin (on l'utilise vraiment beaucoup), il y a de fortes chances que cela s'avère moins cher sur le long terme.
Et bonus, c'est aussi plus écologique.
En tous cas, quand je vois le succès de la campagne, je pense pouvoir dire que beaucoup de gens voient tout cela et ne sont pas dupes. Donc vos liens et vos modèles "plus adaptés" pour des "petites structures". Ben je dis juste: non, rien à voir. Elles ne pourront jamais concurrencer un modèle OpenHardware avec un vrai élan communautaire derrière.
D'ailleurs pour revenir sur le sujet des amateurs/(semi-)professionnels, on peut considérer que ces modèles que vous nommez resteront à jamais pour les amateurs/semi-pro (jamais un pro avec des moyens ne s'achètera une BlackMagic à 2000 EUR qui peut le lâcher du jour au lendemain et avec pas mal de limitations), alors qu'AXIOM va très probablement pouvoir évoluer vers le milieu professionnel également, que ce soit parce qu'avec les options, on va pouvoir avoir des versions bien plus performantes en achetant d'autres composants et en les faisant installer, mais surtout parce qu'on pourra avoir du service derrière! Je rappelle que c'est ce qui joue le plus en milieu pro. On veut pouvoir payer pour avoir un vrai service (le but n'étant pas que ta caméra lâche en milieu de tournage et que tu perdes plusieurs journées de tournage, ce qui coûte bien plus cher que ta caméra!).
AXIOM pourra avoir tout cela une fois que la technique se sera stabilisée (à partir ou après AXIOM Gamma donc), et que des services pourront se mettre en place.
C'est donc un produit qui peut aussi évoluer avec vous. Si vous passez du statut amateur au semi-pro puis pro, la caméra peut vous suivre, obtenir des améliorations, puis vous pouvez avoir des supports de service client adaptés pour vos tournages. Ce n'est donc plus seulement "pas cher pour petite structure", mais cela tout à fait devenir "caméra pro de qualité et avec service adapté" avec le temps. AXIOM pourra jouer sur tous les terrains dans le futur. C'est adaptable. Et ça, c'est aussi un pouvoir énorme.
Ensuite tout cela est à vérifier dans le futur. Mais cela reste le potentiel de l'OpenHardware (et cela sera toujours le cas même si ce projet en particulier devait ne pas réussir ou mal tourner, on ne sait jamais). C'est la "promesse d'un monde meilleur", et c'est ce pour quoi les gens paient aujourd'hui quand ils financent le projet. Ils ne paient pas juste pour une caméra. Comme tu dis, ils peuvent en avoir une tout aussi bien, moins chère, là tout de suite (d'ailleurs je suis persuadé que plusieurs des financeurs d'AXIOM ont déjà certains des modèles que vous citez!). Non ils paient pour faire avancer la société, aller plus loin et faire un pari sur l'avenir. Et si cela ne fonctionne pas avec ce projet là, cela peut fonctionner avec le suivant. Mais si on n'aide pas les premiers, les pionniers, cela ne fait que retarder ceux qui apporteront vraiment le changement (car ils se reposeront sur l'expérience acquise des prédécesseurs).
Acheter un de ces modèles commerciaux que vous citez? Ben ça ne fait que confirmer le statu-quo. C'est pas si grave en soi, mais ensuite c'est un choix de vie. :-)
Je pense perso que c'est important.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cible ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 3.
Ben écoute, y a pas si longtemps, je suis sûr que plein de gens se demandaient l'utilité du téléphone portable pour le grand public (hors professionnels). La technologie avance, et le grand public aussi aime l'idée de pouvoir y accéder, plutôt que cela soit réservé à une "élite" professionnel qui revendique son irremplaçabilité par du matériel hors de prix.
Donc oui, maintenant on fait de la super méga définition au ciné. Alors pourquoi des amateurs n'auraient pas envie, ni le droit, de pouvoir y accéder aussi (en "actif", avec création perso, et plus juste en "passif", devant sa télé)?
C'est bien ça aussi l'OpenHardware: donner accès aux gens à la connaissance et à l'action pour des choses qui étaient réservés aux "pros" jusque là (de même que le FLOSS a fait la même chose pour le logiciel).
Ensuite ça dépend des passions et intérêts. Certains aiment les véhicules et vont dépenser plus d'argent dedans, pourquoi d'autres ne pourraient aimer faire des films?
Aussi je fais clairement la différence entre professionel/amateur et qualité. Dans tous les domaines, je connais des professionnels (= des gars dont "c"'est le métier) totalement incompétent et des amateurs d'un niveau à faire pâlir nombre des dits professionnels. Une fois cela mis en place, je soutiens donc qu'il n'y a pas de raison à ce que les amateurs n'aient pas accès à du matériel de qualité si c'est techniquement/financièrement possible.
Alors pour les amateurs de l'espace, il est clair qu'ils n'auront pas accès à une navette spatiale de sitôt (cas du "pas financièrement possible"), comme ceux amateurs de l'énergie ne pourront s'amuser à faire leur mini-centrale nucléaire à la maison (cas "pas techniquement, voire légalement, possible"). Par contre, franchement avec la technologie d'aujourd'hui, limiter le matos vidéo de qualité aux pros par des prix exorbitants, c'est une limitation artificielle maintenue par des intérêts financiers. Les pros pourront toujours avoir plus de toutes façons: quand tu loues une caméra dans le cinéma, ce qui coûte cher, c'est pas seulement la caméra, c'est aussi les garanties, le service (la caméra tombe en panne, t'en reçois un remplacement dans les 2/3 heures). Le particulier doit faire bien plus gaffe à son matos, doit se débrouiller seul en cas de problème, doit bidouiller, etc. Dans toute technologie, ce qui coûte le plus cher, c'est l'humain (service, support), pas le matos, et c'est très bien (je trouve en effet que le temps qu'un être humain va partager pour régler le problème d'autrui a beaucoup plus de valeur qu'un bout de métal/plastique).
Donc quel est le "besoin"? Y en a pas. Comme y a pas non plus de "besoin" chez les pros (des pros peuvent faire sans 4K aussi. C'est même un concept chez certains. J'ai vu des films pros tournés entièrement sur des téléphones, et c'était le concept du film). Par contre "envie", oui, il peut ou non y en avoir. Et dans ce cas là, si c'est techniquement possible de donner accès au plus grand monde par l'OpenHardware, je dis: ben c'est cool.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 3.
Oui mais uniquement car ils n'ont que cela. Je peux te dire que sur la liste de développement du projet, à chaque fois qu'un développeur se présentait, on lui sautait dessus pour l'accueillir. Mais à ma connaissance aucun n'a réellement fait de contribution approfondie. Par contre y a plus de mecs dans le hardware qui sont arrivés et qui ont effectivement livré quelque chose. Alors bien sûr, les mecs du hardware, ils peuvent aussi développer. Mais bon avoir aussi d'autres gens plus spécialisés en software serait pas un mal.
Ensuite clairement le hardware est la priorité pour le moment, donc c'est pas le pire des cas. Mais je peux te dire que vu de l'intérieur, ne pas avoir plus avancé aussi au niveau software, en parallèle, c'était pas un choix.
Comme dit plus bas, c'est Alpha qui est opérationnelle. Beta sera le résultat du financement.
Sinon la cible de Beta, côté vidéaste, c'est seulement une partie d'entre eux, ceux qui ont pas peur du côté technique et de devoir un peu plus bidouiller que la moyenne. Pour les vidéastes de manière général (ceux qui veulent pas trop se poser de question également), ce sera plutôt Gamma.
Par contre oui les développeurs, ingénieurs, techniciens, scientifiques et cinéastes bidouilleurs sont plus la cible directe de Beta. Ensuite faut pas croire, les cinéastes qui veulent pas de caméra trop expérimentale, mais ont des sous et sont prêts à faire avancer le schmilblick pour arriver plus tard à Gamma qu'ils pourront alors acquérir sont aussi invités à financer le projet!
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: conception modulaire… photographie ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 2.
Ça c'est ce qu'ils ont fait avec l'AXIOM Alpha (prototype actuel). L'AXIOM Beta (le résultat du financement) sera le Truesense KAC12040 de base, mais ils prévoient de proposer des options pour d'autres capteurs (lire AXIOM Beta). Cependant cela dépendra du succès du financement (des "stretch goals").
En fait ça dépendra donc beaucoup de ce que les gens sont prêts à mettre pour passer un cran dans la qualité d'image.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Cible ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 4.
D'après moi clairement. Dans le milieu du cinéma, ils mettent vraiment des sommes faramineuses. Alors dans le milieu amateur ou semi-professionnel, ils n'ont pas les mêmes fonds, mais ils sont tout de même habitué à mettre plus que le particulier dans leur matériel vidéo et audio.
Ensuite le financement parviendra-t-il à son but? L'avenir nous le dira mais même un échec ne pourra être interprété comme un échec plus générique de l'open-hardware dans le cinéma. Plein d'autres raisons peuvent expliquer cela. De toutes façons, perso j'y crois.
Bah les gens sont prêts à changer de matos s'il le faut. Et puis c'est pas comme si y a pas des nouveaux tous les ans (comme dans tous les métiers: les jeunes sont les futurs vieux!). C'est absurde de supposer que tous les cinéastes ont déjà leur matos pour les prochaines années. Dans ce cas là, y aurait pas qu'Apertus dans la merde. Le marché des caméras de cinéma serait verrouillé et plein de boites couleraient! uhuh
Ben ça reste raisonnable pour beaucoup de gens au contraire. Une location de caméra pour un film ciné à petit budget est déjà plusieurs fois ce prix là.
Euh non c'est l'inverse. Alpha, c'est fait, c'est maintenant. C'est le prototype qui est présenté maintenant tout de suite, les premiers tests, les premiers essais. Puis on s'est rendu compte des erreurs de conception, de jeunesse, le fait que ce premier prototype est trop cher et compliqué à dupliquer, que plusieurs des choix et designs électroniques n'étaient pas idéaux, etc. Beta sera donc le résultat suite au financement collaboratif, bénéficiaire de ce qu'on apprend de nos erreurs, et sera ce que les "financeurs" recevront à la fin.
Plus tard y aura gamma, qui devrait être un modèle plus "prêt à l'emploi". Et j'imagine que si ça continue comme ça, un jour il pourrait y avoir delta, etc. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: hcl + client
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal h-node.org : GNU/Linux matériel compatible, base de données. Évalué à 6.
C'est bizarre, la page dit "Laptops are currently unsupported". Quelle est la différence entre un ordi portable et de bureau? C'est la même chose fondamentalement. C'est la première fois que je vois un programme faire une telle différence, et je me demande si le programme refusera de marcher si je le lance depuis un portable, ou bien si le site refusera mes rapports de compatibilité s'il détecte que je les ai envoyé depuis un portable…
Sinon la seconde chose qui me chagrine est que pour rapporter du matériel, il est écrit qu'on doit utiliser une des distribs appuyées par la FSF (c'est à dire pas grand chose d'utilisé, ça fait vraiment un micro pourcentage des utilisateurs), ou une Debian avec seulement le dépôt "main" activé (là y en a plus, mais ce choix est arbitraire).
Encore une fois, je me demande ce qu'il se passe si on envoie un rapport de matos fait depuis une autre distrib. Sera-t-elle refusée? Non parce que cela rend le site beaucoup moins utile si quelques pourcents des utilisateurs GNU/Linux seulement peuvent rapporter.
Bien sûr, je comprends tout à fait qu'ils limitent leur site aux matos qui ne marchent qu'avec du Libre, tout comme je comprends qu'ils appuient particulièrement les distribs qui prennent le parti de ne rien accepter de non-Libre. C'est la FSF, c'est leur rôle. Par contre tout le monde aurait à y gagner si tout le monde pouvait faire des rapports de matos. Y a des moyens de savoir si un matériel donné utilise des drivers/firmware non-Libre.
Sans compter que ça veut rien dire si les dépôts non-Libres d'une Debian sont pas activés au moment du test: il suffit qu'ils aient été activés à un moment pour avoir installé des drivers proprios à ce moment là. De même qu'il est possible aussi de désactiver les dépôts non-Libre sur toute (ou presque, je sais pas si y a des distribs qui ne séparent pas le non-Libre dans un dépôt à part, mais ce serait l'exception) distrib GNU. Sur le coup, ils mettent uniquement Debian à part parce que c'est une collaboration entre FSF et eux. Mais c'est loin d'être une différenciation justifiée.
D'ailleurs même les distribs 100% Libres, les utilisateurs ont pu installer "à la main" des drivers non-Libres à un moment.
Enfin voilà, ce serait bien plus logique de faire une détection automatique du driver utilisé pour un composant particulier, de l'envoyer avec le rapport, et là les utilisateurs qui savent peuvent flagger le driver comme Libre ou non (et ne pas afficher sur le site tout rapport avec un driver non-Libre). Y aurait donc une table dans la base pour les drivers qui dise s'il est Libre ou non et s'il utilise un blob binaire ou non. L'utilisateur n'aura donc pas à se poser de question et pourra envoyer son rapport, qui sera automatiquement ajouté si on sait que le driver associé est Libre, ou refusé avec message explicatif dans le cas contraire. Si c'est un driver inconnu, le rapport peut rester en attente d'autres membres de la communauté à même de dire si c'est un driver Libre ou pas.
D'ailleurs je suis à peu près sûr que leur client envoie déjà automatiquement le driver utilisé au serveur (en tous cas, je vois qu'ils listent les drivers par périphérique sur le site), y a plus qu'à (comme on dit) implémenter le système de validation sur le site. Deuxième chose serait de s'assurer qu'ils l'acceptent et qu'ils soient pas trop arrêté sur leur décision de privilégier certaines distribs.
Je jetterai un œil plus tard, y a peut-être un patch à faire et à leur envoyer. :-)
Mais comme je dis toujours, si quelqu'un aime l'idée et veut proposer avant moi, faites vous plaisir! J'ai pas exclusivité sur les idées et je serais pas contre utiliser mon temps autrement.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 6.
Salut,
Pour répondre au message originel: c'est bien leur but de coupler ce projet avec un projet de montage. En fait ils sont très ouverts sur "comment", ils veulent juste un bon logiciel. Cela pourrait être un logiciel existant qu'ils pourraient améliorer pour le rendre pro et compatible à leurs exigences; cela pourrait être faire un logiciel eux-même qui répondra parfaitement au cahier des charges (oui je sais, c'est trop gros, mais en même temps, ils font aussi une caméra à partir de zéro, ça aussi c'est gros!); cela pourrait se mettre en collaboration avec un projet existant pour travailler main dans la main (y a eu un tel rapprochement avec une société qui faisait un logiciel de montage OpenSource dont j'avais jamais entendu parler. Mais ça n'est jamais allé plus loin que la discussion, sauf si j'ai loupé qqch).
Dans tous les cas, il manque une chose dans leur projet: des développeurs. C'est marrant mais de notre côté dév, on a toujours l'impression qu'on n'a que des développeurs et qu'il manque tous les autres. Ben de leur côté, ils ont réussi à chopper plein de mecs super compétents en électronique, qui ont même déjà participé à des élaborations de caméras du marché pour certains, mais les dévs? Que dalle. Oh y a eu pas mal de mecs qui se sont proposés (dont moi), mais au final sans vrai résultat (j'ai d'autres priorités malheureusement dans l'immédiat). C'est donc assez drôle et même socialement intéressant de constater que le problème n'est pas qu'il manque de mecs pour le hardware, mais c'est juste qu'on n'arrive pas à se mettre ensemble plus.
Enfin oui, tout ça pour dire: c'est l'idée, mais ils n'attendent que les dévs. Qu'attendez-vous?! :-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# Fête de lancement IRC
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 2.
Salut,
Pourrait-on rajouter cette info dans la dépêche. Voici l'email envoyé sur la mailing liste communautaire:
En gros, une heure avant la fin du décompte, ils proposent à toute la communauté de se rendre sur IRC pour discuter, et ils partageront quelques "trésors" de l'histoire du développement d'AXIOM.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Je suis tout fou-fou à l'idée que ça marche! :)
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 6.
Je suis assez d'accord. Pour moi cinelerra, cela fait longtemps que je ne le considère même plus dans mes comparaisons et tests de logiciels de montage vidéo.
Les dernières fois où j'ai essayé de l'utiliser, il y a peut-être 2/3 années de cela, il était tout simplement instable. Il crashait toutes les 10 secs pour un oui ou un non. Donc franchement j'ai laissé tomber avant même de savoir si le logiciel "pourrait" être bien ou non, s'il ne se crashait pas constamment.
Les fois où j'ai essayé de le compiler, à peu près à la même période, soit 2/3 ans auparavant aussi (donc peut-être qu'à l'époque je m'y connaissais moins aussi), c'était la croix et la bannière.
Il n'est même plus dispo de base dans pas mal de distributions. Déjà parce qu'il dépend fondamentalement de la libfaac qui a des problèmes de brevets (or si certains logiciels ont une dépendance optionnelle, cinelerra apparemment ne peut pas faire grand chose sans libfaac). Donc les distribs qui n'ont pas de dépôts teintés ne proposent pas cinelerra (par exemple: mageia). D'ailleurs je viens de vérifier, même si ma Linux Mint propose libfaac, elle, ben y a pas de cinelerra pour autant dans les dépôts. C'est clairement plus un logiciel prioritaire pour personne.
Enfin regarde le résumé des commits du projet communautaire sur les dernières années sur ce site: https://www.openhub.net/p/cinelerra/commits/summary
Y a eu quasi absence de commits entre 2007 et 2014! C'était donc un projet mort. Je remarque d'ailleurs que ça reprend seulement depuis avril 2014 (tout frais! Je jetterai un œil de temps en temps pour voir si le projet se relance vraiment ou si c'est juste un soubresaut. Si ça continue à un tel rythme de dizaines de commits par mois pendant des années, ça peut revenir dans la danse).
Bon apparemment cinelerra est aussi développé par une société, Heroine Virtual LTD, mais bon la page de download indique tout de même « Downloads have no support or warranty and are not community approved. Linux derivatives are so incompatible, don't be surprised if the source code requires some tweeks and the binary doesn't work. » ce qui donne pas confiance dans leur qualité de développement (chez moi avec les bons outils, y a pas d'incompatibilités extraordinaires entre les diverses distrib GNU/Linux. Qu'on dise "attention testé seulement sur…" ok, mais là c'est bizarre comme tournure). Mais bon on peut s'attendre dans ce cas à ce que le logiciel s'améliore?.. À voir… Dans tous les cas, le problème de manque d'ouverture et d'absence de dépôt de source accessible au public rend ce développement plus hasardeux (ils font juste des sorties).
Et on peut clairement lire que ce n'est plus la priorité de cette boîte. Ils l'ont présenté à quelques "shows" entre 2000 et 2004, puis plus rien, d'après leur site. Je parle même pas du copyright de bas-de-page: «(C) 2013 Unemployed, flat broke Programmers»
Je constate aussi qu'il y a deux site web pour la version communautaire: le site originel cinelerra.org, qu'ils ont et un nouveau site web: http://cinelerra-cv.org/
Apparemment cinelerra.org n'a pas été renouvelé et quelqu'un s'en est emparé. Mais de façon amusante, ça parle toujours de Cinelerra, mais seulement de la version pro, j'ai l'impression (est-ce la société Heroine Virtual qui a racheté? Le whois ne dit pas). Et il n'y a rien pour télécharger (par contre, on nous demande notre email pour un "download update").
Enfin bon, tout ça m'a l'air bien compliqué. Peut-être cinelerra mérite-t-il de nouveaux tests? Mais j'espère vraiment qu'ils ont amélioré la stabilité car c'est vraiment là où ça pêchait.
Tout ça pour dire que cela ne m'étonne pas qu'on ne considère plus cinelerra dans la course. Blender aussi à l'époque les gens disaient qu'ils avaient un UI dur à prendre en main, etc. Ben ils ont bossé comme des dingues pour s'imposer (et changer ce qu'il fallait) et ils sont loin de cette époque maintenant. Cinelerra aurait pu faire la même chose, mais j'ai l'impression que cela fait longtemps qu'ils se sont laissé aller.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Lien ?
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Lancement de la campagne de financement de la caméra libre AXIOM Beta 4K . Évalué à 4.
Clairement oui, le lien est manquant. C'est un peu inutile sans lien. Lien vers le site du projet avec décompte: https://www.apertus.org/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Les liens qui surprennent
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Journée du logiciel libre 2014 : des activités gratuites à Québec. Évalué à 2.
Ok.
Je serais personnellement pour prévenir l'association LinuQ, et retirer le lien de linuxfr (éventuellement temporairement le temps qu'ils trouvent le problème) avec un petit message expliquant pourquoi. Je doute qu'un lien en première page de linuxfr qui redirige sur un site de cul soit vraiment idéal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Les liens qui surprennent
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche Journée du logiciel libre 2014 : des activités gratuites à Québec. Évalué à 2.
Uh! J'ai eu exactement la même page que toi à l'instant (sauf que la mienne, y avait pas de culotte)! Mais si je réessaie immédiatement après, ça me donne dorénavant la bonne page. Y a un problème quelque part là, le système de redirection de linuxfr n'aurait-il pas été corrompu et redirigerait de temps en temps vers ce site? Ou alors c'est le site du lien lui-même qui aurait ce problème. Mais dans les deux cas, je doute que ce soit normal.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pourquoi ne pas prendre une "rolling release" comme ArchLinux
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal OpenMandriva Lx 2014, sortie presque inaperçu… . Évalué à 2.
Ah ok. On entends tout de même pas mal d'histoires terribles sur les problèmes rencontrés en utilisant Debian testing. C'est pour cela que je faisais cette distinction.
Je me demande d'ailleurs à quel point on peut tester un build en une seule semaine. Dans Gentoo, je sais pas combien de temps les paquets restaient "unstable", mais cela pouvait durer longtemps, surtout pour les petites applications pas très utilisées (qui parfois restent même indéfiniment "unstable" si le peu d'utilisateurs fait que personne ne remonte rien). Évidemment les gros logiciels connus eux passent stable bien plus rapidement (mais en combien de temps? Une semaine me paraît tout de même un chouille court, non? Quoique si c'est Firefox, les retours doivent être par dizaines au bout de quelques jours…).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 2.
Ah ok, bon ben voilà. S'ils inventent encore d'autres trucs pour contourner le fait qu'ils prennent pas de fichiers… C'est pourtant simple les fichiers. Un concept que tout le monde comprend parmi les développeurs, non? Pourquoi remplacer cela par un service de copier-coller en ligne?
Effectivement ça peut déranger d'envoyer ton patch sur la mailing list, mais donc uniquement parce que c'est pas vraiment l'endroit (c'est dur de faire du suivi dans un contexte de flot d'emails. On perdrait les patchs!). D'ailleurs certains projets filtrent même les fichiers des emails (pour éviter les gens qui mettent d'énormes fichiers, ou bien les fichiers à but malveillant, etc.). Sur les mailing lists GIMP par exemple, ton email arriverait sans le patch. Tout ça pour dire que c'est vraiment pas l'endroit.
Ensuite oui, je suis d'accord que ça veut dire devoir s'inscrire encore à un énième site pour déposer son rapport de bug. Et ça c'est chiant. C'est un problème qui existe depuis l'aube de l'internet. Mais centraliser tout dans les mains d'une unique entreprise n'est pas, et ne sera jamais selon moi, la solution (même si c'est effectivement celle que poussent comme par hasard toutes les entreprises, entre les "connect by Facebook" et autres trucs du même acabit). Les solutions acceptables seraient plus dans l'optique openid, avec le succès (peu) qu'on connaît (mérité peut-être car je ne trouve pas la solution technique si adéquate). En attendant, faut faire avec. Je préfère tout de même faire un énième compte sur le site d'un projet auquel j'ai décidé de faire confiance (sinon je leur enverrais pas de patch probablement), plutôt que pousser l'ensemble des développeurs du Libre à s'enfermer dans un unique "réseau social développeur", propriétaire et sous le contrôle d'une unique société.
Note que j'ai rien contre les sociétés qui font cela. C'est une très bonne idée et un plutôt ok service dans le cas de github. Je suis juste pour la diversité, et je refuse de mettre tous mes œufs dans un même panier. Donc je ne ferai jamais la promotion publique d'un service en particulier. Enfin si, je peux dire "c'est bien, ça marche" (c'est le cas de github: "c'est bien, ça marche", mais ça a vraiment rien d'une révolution et leur workflow est tordu et mal-foutu par endroit. Cf. cette discussion), si on me demande, mais ça s'arrête là. :-)
Tout pareil: c'est le principe de git. Je vois pas le rapport avec le fait que ce soit sous github, sourceforge, auto-hébergé ou autre. À te lire, on dirait que github a inventé git!
[Note: pour être clair, je réponds à Moonz, pas à Zul. Mais comme je suis globalement d'accord avec Zul, j'ai pris son message comme base.]
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pourquoi ne pas prendre une "rolling release" comme ArchLinux
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal OpenMandriva Lx 2014, sortie presque inaperçu… . Évalué à 0.
Moi, quand je dis "rolling release", j'entends "stable". Je sais pas comment c'est sur Arch, mais en lisant la description plus haut, cela m'a l'air similaire à ce que j'avais sur Gentoo: des paquets stables et déjà testés. Mon expérience Gentoo fut vraiment très satisfaisante. C'était très stable. Une mise à jour ne pêtait pas tout.
Ça ne dit pas qu'il ne peut y avoir un problème innattendu qui pête ta machine, mais comme pour toute autre distribution stable: ce serait une erreur passée entre les mailles du filet, et à corriger rapidement, non la norme.
Debian testing au contraire, c'est de l'expérimental (d'où le nom "testing"). Les utilisateurs sont des contributeurs qui acceptent d'être les premiers à essayer des paquets non-testés, pour ensuite remonter les problèmes, avec tous les risques que cela comprend. Ensuite c'est peut-être à considérer "rolling release" aussi, mais c'est juste pour dire que c'est pas du tout la même catégorie. C'est pas fait pour être sur ta machine principale (enfin tu peux, mais à tes risques et périls). Gentoo par contre si (note que sous Gentoo aussi, on peut récupérer les paquets non-testés si on veut, et on se retrouverait alors dans le cas Debian testing. Ce qui est super bien ceci dit, c'est la gestion fine des tests: un flag au niveau des paquets. Donc on peut télécharger certains paquets en tests, et le reste en stable par exemple).
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 9.
La discussion, qu'elle ait lieu dans une mailing list, sur un bugtracker ou sur github, je vois pas la différence.
Ensuite j'ose espérer que les mainteneurs github testent les patchs sur leur dépôt local, et se contentent pas de croire sur parole un inconnu. Quand ça vient d'un contributeur habituel ou que c'est un patch très mineur (changement de string ou autre), ok, se contenter de regarder la syntaxe peut suffire. Mais sinon, même un patch d'une ligne peut casser des choses, et la plupart du temps, ne pas tester n'est pas conseillé.
Donc déjà à partir de là, faut quitter son navigateur et appliquer le patch. Une fois fait, testé et approuvé, y a juste à
git push. Avec github, il faudrait revenir dans son navigateur pour faire le changement.Ensuite quand tu me dis "pas à s'embeter, ton nom tout ça tout comme il faut", j'ai tendance à penser que tu n'as jamais fait ou reçu de patch git, ou alors je comprends pas ce que tu veux dire.
Quand quelqu'un m'envoie un patch git, je le
git am, et j'ai ungit logparfaitement "comme il faut", avec le nom de l'auteur et son email, la date de son commit (pas seulement la date à laquelle j'ai appliqué le patch, qui elle correspond au CommitDate), et finalement le message de commit qu'il avait déjà préparé. "Pas à s'embêter", comme tu dis. Une fois bien testé et approuvé, j'ai juste àgit push, et c'est fini. On gère un patch envoyé en deux commandes (avec les commandes de build, etc. et tests entre-deux normalement, mais ça, c'est pareil quelque soit le workflow si on fait les choses consciencieusement), en restant dans sa console.Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 9.
Ça je suis d'accord. Je ne me suis d'ailleurs jamais plaint à un mainteneur d'un projet sur github directement, et je suis le processus demandé douloureusement mais silencieusement. Je répondais juste à la remarque générale comme quoi tu trouvais ce nouveau workflow git (car non ce n'est pas le workflow prévu pour git, j'y reviens plus bas) révolutionnaire.
Tututut. Demandons par exemple au développeur originel de git, Linus Torvalds: https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Donc non clairement, ce n'est pas le workflow prévu par git.
Ensuite il y a des logiques de workflow différentes, et chacun est libre, encore une fois. Je n'arrive pas avec mes gros sabots voir un mainteneur d'un projet et lui dire que son workflow pue et qu'il devrait changer. Mais lire que git est fait pour ce workflow, ben non clairement. Là faut pas abuser, surtout quand l'auteur de git a déjà dit maintes fois que c'est pas le cas et refuse tout "pull request" passant par le système complètement cassé de github.
Comme dit juste au dessus, c'est pas vrai. Cette façon de faire est une spécificité github. Mais effectivement quand on reste dans la "communauté" github de gens qui ne connaissent que cette façon de faire, on a l'impression que tout le monde aime cela. Ben moi en dehors de cette communauté, je rencontre aussi plein de gens qui n'aiment pas.
Je fais des branches à part pour à peu près tout (je suis un grand partisan d'un workflow par "branche de fonctionnalité"), mais il y a plein de cas pour lesquels ne pas avoir 2 branches séparées est valable, ne serait-ce que pour 2 patchs mineurs sans aucun rapport, et sur des fichiers totalement différents (ils ne peuvent pas interférer). En gros faut quand même distinguer une branche de fonctionnalité d'un bug fix de quelques lignes.
Ensuite, dans mon précédent message, je parlais pas de cherry-pick (j'ai pas compris pourquoi tu m'en parlais). On ne fait pas de cherry-pick tout le temps, effectivement ce serait très lourd. Non on
git am(on peut legit applyd'abord s'il s'agit d'un patch compliqué et qu'on veut le tester en profondeur sans avoir peur de le pousser par erreur) un patch proprement formatté par github, avec message, auteur et tout. On teste, puis on pousse.Pour des petits contributeurs, il est normal de faire les choses par fichiers. Rends toi compte que le système à la github est en train de pousser les gens à mettre en ligne un dépôt public, pour des fois un patch d'une ligne, et qu'ils ne reviendront jamais sur ce dépôt? C'est le marteau pour écraser la mouche. Github simplifie cela en rendant cette partie facile, mais la contrepartie c'est qu'on se retrouve à avoir des dizaines de clones publiées pour plein de projets (les fameux "forks") qui sont juste des zombies laissés à l'abandon.
Donc non le coup de merger des branches, c'est bien entre contributeurs importants, ceux pour qui effectivement cela devient plus pratique d'avoir une branche publique. Tu penses que combien de personnes ont leur propre branche sur les projets énormes comme linux? Les divers mainteneurs, et quelques contributeurs très prolifiques. Et encore souvent, eux se feront des branches sur un même dépôt, pas leur propre dépôt!
Et tu penses que faire son propre dépôt devrait être la norme, même pour les contributeurs mineurs? C'est de la folie. C'est pas pour rien que
git send-emaila été inventé. C'est parce que contribuer par patch est la norme des petits contributeurs, les branches publiques, on les laisse aux gros contributeurs.Encore une fois, de la littérature par l'auteur de git: https://www.kernel.org/doc/Documentation/SubmittingPatches
Comme tu le vois, les pull requests sont un seul point, le dernier, pour envoyer des patchs (point 16 de la section 1). Tout le reste se concentre sur le formattage de patch en fichier à envoyer par email (note que lu comme ça, ça a l'air compliqué, mais je pense que c'est parce que c'est un vieux texte. De nos jours, quasi tout ce blabla se fait en une ligne:
git format-patch origin/master, "master" à remplacer par une autre branche selon la branche qui sert réellement d'origine). Parce que franchement faire un dépôt public pour un patch, c'est vraiment en faire un peu trop.Je pense que github a même cet effet pervers d'empêcher les gens à apprendre à connaître vraiment git et son fonctionnement. On rencontre régulièrement des gens qui veulent qu'on fasse tout sur github, mais c'est uniquement parce qu'il ne connaissent que cela et qu'ils se rendent compte qu'il ne savent pas utiliser git en dehors des boutons du navigateur (sérieusement, le fait que tu me répondes "cherry-pick" à un "format-patch" par exemple me fait des doutes quant à ta compréhension de comment marchent les patchs formattés par git; le fait que tu me parles de "branches" alors que github fait même carrêment des clones de partout aussi).
Oulaaaaah! C'est une très mauvaise idée… sur toutes les branches publiques! Encore une fois, il y a plusieurs logiques. Certains vont effectivement rebaser des branches de fonctionnalités, même publiques (il y a effectivement 2 écoles majeures: les rebaseurs fous, et les mergeurs fous. Curieusement tu m'as l'air d'être un mix des deux…). Mais c'est loin de faire l'unanimité. Encore une fois, tu dis ça à Linus, il t'insultera allégrement. Sa logique, qui est le workflow du projet du noyau linux, et donc probablement très répandue, est de ne jamais rebaser une branche de fonctionnalité publique. C'est exactement la même chose que master, dont tu parlais plus bas. Une branche publique, quelle qu'elle soit, se retrouve copiée dans les dépôts locaux de tous ceux qui ont cloné le dépôt. Et il est tout à fait possible que quelqu'un ait commencé à bosser dessus. Rebaser dans ce cas fout le bordel (oblige de créer une série de patchs et/ou stasher pour ce qui n'est pas déjà sous la forme de commits, supprimer sa branche locale, la recréer, et ré-appliquer tous ses propres patchs. Très lourd). En outre tu casses un historique de hash de commit, ce qui peut créer des problèmes de discussions. À partir du moment où une branche a été rendue publique, on a pu discuter certains commits sur une mailing-list/chat/tracker/etc. Et on rend tout nommage de commit inutile si on se permet de renommer (par rebase) à tout va.
Alors bien sûr, master est la pire, puisque c'est la branche principale où les chances que quelqu'un ait déjà commencé à bosser à partir de là est la plus forte, mais les autres branches publiques sont aussi en danger.
La technique du rebase sur les branches de fonctionnalité publique peut fonctionner "à peu près" pour les projets avec très peu de développeurs, et en particulier où en général une branche de fonctionnalité ne sera éditée que par une seule personne. Dans le cas de github (qui encore une fois, ne fait rien comme les autres), ça passe souvent car non seulement y a qu'un mec qui bosse seul sur la branche, mais surtout il a son propre dépôt avec en général le seul à y avoir les droits d'écriture. Il reste tout de même le problème de l'historique des hashs, mais au moins on ne se marche pas sur les pieds. En gros ils ont réglé le problème du travail collaboratif en le rendant intrinsèquement non-collaboratif. :-/
Et encore une fois, parce que malheureusement tu sors à chaque fois que ce sont les workflows prévus pour git, et donc je crains que tu me croiras pas si je te dis qu'énormément de gens en dehors de github ne veulent pas de cela, je te redonne le workflow de Linus: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
J'aime pas jouer à l'argument d'autorité, mais tu me laisses pas le choix avec tes arguments de "statistiques Bullshit©", qui sont effectivement erronés (et surtout biaisé par le prisme de ceux qui sont beaucoup sur github, je pense). :P
Mouais je comprendrais jamais comment on peut trouver sain cette nouvelle mode de tout forker. Comme tu le confirmes, rien n'est clair. Et je suis désolé, même le "forked from" est loin d'être la première chose que tu vois en arrivant sur la page (encore une fois, pour ceux qui passent leur temps dans github, c'est peut-être évident, mais pour les autres…).
Avec ton exemple, je suis en effet totalement dans le flou. Y a une vingtaine de forks, la plupart quasi les mêmes, mais parfois avec une petite différence, rarement mais parfois avec beaucoup de différences. Et ironiquement, le dépôt original a été vidé (et le README ne passe pas la maintenance justement). Donc si t'es un dév, ou un utilisateur, tu fais quoi? Tu testes les 21 forks un à un pour voir ce qui a changé?
Franchement ce système de fork, c'est plus du réseau social qu'autre chose (plein de gens me forkent! Oh oui allez y, forkez moi! ;-p), mais je trouve cela anti-productif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 10.
Sérieux, je suis pas d'accord. Github marche bien quand on est toujours dedans, et qu'on ne bosse qu'avec ça. C'est d'ailleurs le but de la plateforme: enfermer les développeurs à l'intérieur et faire en sorte qu'ils n'en sortent pas.
J'ai essayé l'autre jour de patcher des bugs dans un projet hébergé par github. Au début, je fais un rapport de bug, me disant que je vais y uploader mon patch (correctement formaté avec
git format-patch origin/master). Ah pas possible. On peut seulement uploader des images. Sérieux?!Je me suis retrouvé à devoir "forker" le projet (sur le site web seulement), modifier mon .git/config pour ajouter mon remote, pousser mes commits, retourner sur le site, et finalement faire une demande de pull (on peut même pas faire une demande par commits, mais pour tous les commits d'une branche donné. Uh?!). Sérieux, on trouve ça plus simple?!? En plus si je veux suivre le projet, je me retrouve à devoir gérer 2 remotes depuis mon dépôt local. Note que c'est courant voire normal de gérer plusieurs remotes si t'es un mainteneur d'un gros projet, mais c'est lourd pour un contributeur intermittent (qui envoie un patch tous les 36 du mois) car on peut se retrouver vite à s'emmêler les pinceaux. Avoir des branches locales et se baser sur un seul remote est bien plus facile.
Bien sûr la raison est de te pousser à gérer tout cela dans ton navigateur, sur le site web, puisque leur UI a un workflow adapté à ces logiques incongrues. Mais franchement je préfère de loin gérer le plus de truc possible dans ma console.
Je parle même pas de la sémantique. C'est pas un fork que je veux faire! Je veux juste patcher un projet, pas le forker. C'est d'ailleurs terrible pour les petits projets: combien de fois (des dizaines!) je me suis retrouvé sur un projet github à me demander s'il s'agit de l'upstream ou non. Pour des petits projets, un moteur de recherche peut répondre plusieurs pages github et la première n'est régulièrement pas l'upstream.
Non, moi si je veux publier un projet, je reste sur tuxfamily ou autre petit hébergeur. Au moins, ils essaient pas de se faire passer pour du réseau social.
Et je dis tout ça, mais j'ai pas mal utilisé Github, quotidiennement et des milliers de commits lorsque je bossais pour une startup qui l'utilisait. Ça marche très bien tant qu'on reste dedans et qu'on s'adapte à leur logique bizarre de fork, y a pas à dire. Mais c'est loin d'être la meilleure logique de contribution.
Sinon pour répondre, moi aussi, c'est pour moi: je veux réparer des logiciels ou avoir des fonctionnalités, je les code. J'ai appris à ne plus me reposer sur et attendre les autres, mais à faire les choses moi-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: pilote noyau
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche scdrand: alimenter le pool d’entropie du noyau à partir d’une carte à puce. Évalué à 3.
C'est vrai, y a de quoi se poser la question. D'ailleurs quelque chose d'autre m'a intrigué: pour les utilisations "routinières" dont tu parles (signer, déchiffrer, authentifier), s'il n'y avait pas la carte, les logiciels de cryptage (GnuPG en tête donc) tirerait profit de /dev/(u?)random, non? Donc finalement, ton programme ne pourrait-il pas tout simplement remplacer Scdaemon de manière transparente? GnuPG ne communiquerait plus directement avec la carte, mais en cherchant de l'aléa dans les /dev/(u?)random, il utiliserait indirectement la carte en fait, sans même avoir à le savoir.
Ou alors la carte a d'autres fonctionnalités et son rôle n'est pas uniquement de produire de l'aléa rapidement. Y a un processeur dédié pour accélérer des calculs de crypto aussi, peut-être?
Comme je le disais, je connais rien à ces cartes, donc ces questions sont peut-être un peu ridicules, mais bon. C'est bien pour ça qu'on demande un article supplémentaire dessus. ;-)
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]