Ce n'est pas identique, "curl | sh -" nécessite un effort de la part du fournisseur: il faut écrire un script shell.
Sinon, l'ancien triptyque "./configure && make && make install" ne s'applique qu'aux projets dépendants des autotools qui sont, je pense, en perte de vitesse (je dirais même que c'est pas plus mal! On est trolldi c'est donc permit)
En gros, sur des machines que tu peux rattraper sans intervention coûteuse (le coût étant de diverses natures: argent, temps, réputation, etc) quand ça va merder.
Malheureusement, seuls les gens qui ont eu a gérer un parc de plus de 3 machines en plus d'autres tâches sont enclins a penser a ce genre de «détails» je le crains.
redémarrer sans cesse les process c'est tout pourri pour moi et c'est ce que fait systemd
Je suis intéressé par plus d'argumentation la dessus: pourquoi c'est pourri?
Accessoirement, ce n'est pas l'apanage de systemd, les daemontools le font aussi, et quand il faut interagir avec des systèmes (hard/soft) sur lesquels on n'a pas de maîtrise, ça sauve. Ou si on code de la merde aussi.
J'ai eu tous les cas :/
J'ai l'impression que Google se tape cette réputation surtout parce qu'ils tentent beaucoup de choses. Mais je ne trouve pas leur politique qui choquante que ça.
C'est un fait, qui ne tente rien n'a rien, et pour une boîte, c'est sain de drop des projets pas rentables.
Framasoft aussi ferme des services.
Mais on a accès au source et on peut host un instance pour refournir le service, pas avec google.
Ça fait partie du cycle de vie de tout service. Soit tu héberge toi pour t'assurer que le cycle de vie correspond à ton besoin soit il faut vivre avec (ce qui n'est pas forcément si compliqué si on a un peu fais attention).
C'est, je pense la grande différence: Framasoft n'utilise en public que des logiciels libres (en privé, je sais pas) dont le code est accessible. Ce n'est pas le cas de google.
En fait, ça serait plus simple (pour moi) d'avoir un argument correct si les logiciels utilisés par Framasoft étaient sous affero, mais vu que je suis déjà pas fan de la GPL, je vais pas le demander.
Je suppose qu'un résumé possible est: «Moi, Freem, ai une certaine confiance dans le fait que Framasoft n'utilise que des logiciels dont je peux avoir le source pour les services dont je dépend, confiance que je n'accorde point a Google.»
Ce qui indique clairement que j'ai jamais été vérifier. Du coup.
Par contre, moi, je suis un utilisateur et un peu contributeur de LL, je n'utilise pas le LL juste parce que c'est souvent gratos. Enfin, ce n'est plus le cas.
Je suis sûr que la majeure partie des râleries contre google sont liées a ça.
Et que s'il y en a peu pour framasoft, c'est parce que c'est peu connu, hors de «notre sphère idéologique».
Interface de merde. Force l'usage de la souris par clavier stupide. C'est une des raisons pour lesquelles je me ferais un plaisir de les envoyer chier dès que je prévois un gros emprunt (maison). Perso, suis prêt a payer pour ne pas avoir cette merde, mais faudrait une garantie que ça dure…
Concernant l'UX : Bourso et BNP sont partis sur une interface web de type tablette
Tiens, ben, le CA aussi dis… et c'est horrible a utiliser sur PC. Je suis pas le seul a m'en plaindre, mes parents aussi (oui, chez nous, on a tendance a ça, suivre ce qu'on nous a définit dans l'enfance tant qu'il n'y a pas d'intérêt manifeste a changer). Compte tenu de ma parenthèse, ça commence a peser sévère sur les raisons de changer!!
Un tableau des transactions normal. Voir Excel ou Calc pour un bon exemple.
Merci d'aller voir csv aussi. Et 0 raison de pas le faire, ce dernier est importable et exportable par tous les outils que j'ai pu utiliser jusqu'a présent, ce qui est loin d'être limité à Excel et Calc, mais les inclue!
Bah, d'un autre côté, les bronzonizations sont vachement moins intéressantes que ce message, et personne leur dit d'aller coller ça dans les liens.
Bon, accessoirement, un lien ne permets pas un titre assez long pour dire ce qu'on pense du lien. Et, du coup, perso, j'aime pas les liens. D'ailleurs, y'a rarement des commentaires, et c'est encore pire pour les échanges réels.
Il n'y est pas non plus possible de demander des alternatives (certes, ça aurait plus ça place dans les forums, mais vu qu'il y a annonce aussi, peut-être pas tant que ça?).
Posté par freem .
En réponse au journal quick start pour coco/R.
Évalué à 2.
Dernière modification le 16 juillet 2020 à 21:51.
Il y a 3 langages supportés, et vu le code je pense qu'il ne devrais pas être trop difficile de porter la bête pour un autre langage si la syntaxe dérive du C et que l'orienté objet est supporté.
Pour du python par contre, ça risque d'être plus chiant, mais je suis pas expert.
Et pour l'effort de rédaction, je vais juste profiter de mon propre journal pour virer mes notes locales, ça a mis du propre et ça m'a permis de régler un bug dans l'exemple du coup j'y gagne aussi :)
Par contre j'adorerais avoir un contre exemple de la même syntaxe avec d'autres outils.
echo foo bar | ./cmdline
-- line 1 col 5: EOF expected
bon, c'est surtout que mon fichier de règles ici est bien trop trivial hein. Avec des règles plus complexes et surtout plus complètes c'est mieux.
Il aurait suffit que je change la production argv en argv = identifier { option } '\n' pour avoir:
printf "foo bar\n" | ./a.out
-- line 1 col 5: "\n" expected
J'ai vu des messages d'erreurs plus sympas lors de mes essais (qui sont sur un «langage» plus évolué), et ce, alors même que j'ai éludé la question de la gestion des erreurs.
Zut, j'ai oublié de préciser quelques détails au sujet des fichiers .frame fournis par l'upstream:
ils sont écrit dans du C++ pré-2011 (et ça warn dur, même si j'ai patché les miens pour résoudre ce problème), qui n'utilise pas std::auto_ptr
clang --analyze détecte un bug
de même, au moins une variable n'est jamais utilisée
pas mal de padding qui peut être réduit dans le code généré
le copyright utilise des fins de lignes de type CR/LF, «à la Windows», un petit coup de dos2unix sur les fichiers .frame résout le problème à la source
Concernant mes patchs perso:
correctif du bug (je pense que c'est le seul patch vraiment important):
Mon log actuel (je pousserais sûrement upstream (dommage qu'ils aient pas importé l'historique quand même) quand j'aurai un peu plus de connaissance sur le code de base):
fbdf15a fixed using nullptr as non-null param (found with clang analyzer)
d96c82a removed unused charSetSize
627b6de fix weak-vtable
662fe62 fixed remaining implicit conversions warnings
8ee6cab fixed most implict sign conversions
dd097f8 fixed most shortens 64 to 32 warnings
43fb34f fix extra-semi
548b34a no longer use 0 as nullptr
d50ecea slightly reduce padding
1a76de4 generated code no longer use reserved macros
6cd6446 no more shadown vars
12b8daa no longer generate code with old-style cast
b1ccb79 NULL -> nullptr
68aa815 dos2unix
5fb038c initial commit
C'est sûr. Et au pire, ça m'a permis de revérifier certains points, d'éclaircir mes notes, et ça me resservira peut-être quand je ne serais pas sur ma machine ou qu'il me faudra expliquer comment ça marche a un collègue (ça m'est déjà arrivé avec des journaux précédents).
C'est juste que j'aurai aimé avoir plus de recul sur le sujet (que je ne maîtrise pas du tout), mais bon, comme tu dis, il n'y a que 24H par jour :)
En plus, pas impossible qu'il y ait justement de quoi compléter mes notions dans les commentaires.
C'est vrai. Je pense que c'est fait exprès, mais c'est un mauvais choix à mon avis.
De mémoire, le but était de mieux toucher les gens qui se baladent juste sur le web, au détriment de la partie de leurs utilisateurs qui considèrent qu'un album est un tout.
Fait bien longtemps que j'y suis pas allé pour le coup. Ni sur dogmazic d'ailleurs.
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
La seule solution au final, c'est d'embarquer les tickets dans le repo. De ce point de vue, fossil est très intéressant. Le problème, c'est juste qu'il faut apprendre a utiliser un nouvel outil, ce qui va freiner les premières contributions de la majorité des contributeurs.
Pour les autres DVCS (et notamment git), il existe divers projets pour ça, mais même si j'aime énormément l'idée (bien plus que de devoir me taper l'UI de github, tu peux me croire), je garde mes doutes sur les implémentations (par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Il faudrait que je reprenne un peu le temps de regarder d'ailleurs.
Il est quand même moins probable que, par exemple, google oublie de payer son domaine que toi ou moi. Ou que leur compte bancaire soit fermé suite a bronsonisation du propriétaire.
Pour le fait de leur politique, c'est clairement un fait, surtout pour google. D'ailleurs ils avaient leur propre forge pendant un temps, mais je pense que peu de monde avait vraiment envie d'héberger leur code chez eux, pour entre autres cette raison que tu cites.
D'une manière ou d'une autre, il n'y a vraiment que la réplication qui puisse freiner le problème de la disparition des sources.
Le fait que ce soit maintenant impossible ou presque de faire des recherches par album.
Leur "nouveau" site est anti-ergonomique pour qui veut écouter un album, mais, j'accepte que c'est un choix.
Pour ce qui est de Dogmazic, en revanche, ça s'est amélioré, même si c'est toujours pas ça (c'est un peu de ma faute, je pourrais p'tet aider, même si je suis une bite ((ouai, c'est fait exprès pour rappeler que non, les références au mâle ne sont pas toujours positives)) en frontal).
Il faut dire que dogmazic est un site commercial, ils ont besoin de revenus, et c'est normal. Je ne leur en veux pas.
D'un autre côté, ni l'un ni l'autre ne suivent vraiment le libre, dans le sens ou il est rare que les sources (partitions, paroles, etc) soient fournies avec.
Il s'agit d'ailleurs d'un problème récurrent pour les gens qui font des jeux vidéo libres (je ne fais que contribuer): rares sont les ressources.
Personnellement ça m'est déjà arrivé de renoncer à rapport un bug ou de proposer un correctif, par ce que j'étais en train de faire autre chose en même temps et que j'avais la flemme de créer un compte sur un n-ième site (oui je sais, c'est pas bien).
Pareil.
D'un autre côté, j'ai le même effet maintenant avec github en vrai, parce que j'ai tendance a caler mon patch dans (ou en pièce jointe à) la réponse, et a chaque fois, même si ça améliore les choses, il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Pour moi, ce n'est pas que MS soit l'actuel proprio de GH le problème, le problème c'est la bureaucratie inhérence à la façon de gérer les projets par "push-request".
Ça ne date pas du rachat, hein.
Mais ça a toujours été plus proche de la cathédrale que du bazar sur lequel, notamment, linux et ses distributions sont bâties.
Et dans le cas des cathédrales, les BSDs ont prouvé qu'héberger sa forge est efficace, mais ce type de forges se basent sur les échanges de mails.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
La migration sous Gitlab n'a pas l'air si simple, si on en croit le projet PeerTube,
Et qu'en est-il de l'inverse?
De GL ou GH vers d'autres forges moins populaires?
Qu'en est-il aussi des raisons? Techniques? Une BDD c'est toujours chiant a migrer c'est évident, les logiciels sont pas conçus de la même manière…
Par ailleurs, le fait d'avoir l'intégralité des projets centralisée facilite grandement l'analyse statistique des projets, sans avoir a dupliquer une multitude de dépôts de sources différentes.
Hein?
on ne peut pas lancer sa propre instance de Github, contrairement à Gitlab
Et tu ne peux pas instancier ton instance gitlab chez toi sans faire tourner de code proprio. A moins que, et ça me surprendrais, l'instance publique ne fasse tourner que du code sous Affero GPL?
Enfin, je me permets de penser que si, le fait d'appartenir à Microsoft, dont l'historique anti-LL est particulièrement lourd, est un problème. Malgré la communication intense que cette entreprise déploie pour nous convaincre que "Microsoft loves Linux"…
Ça s'appelle du bullshit chez moi. Moi, je suis un techie bas de gamme, je n'accepte que les arguments efficaces, mes parents ont oublié de m'installer le plugin pour regarder la marque avant de critiquer.
Github est aujourd'hui en situation de quasi monopole pour l'hébergement des projets libres.
Ben, tout le monde a tapé sur Sourceforge (qui héberge cela dis toujours les gros fichiers de bien des projets dont le dev se fait sur GH ou GL hein…) donc on l'exclue.
Y'a quoi d'autre? GitLab? Pas monopole, certes, mais mais 100% libre non plus, leur plateforme n'utilise pas la version libre.
Au final, le but des utilisateurs de GH, c'est de réduire le taux d'emmerdement des nouveaux contributeurs et des développeurs.
Pas besoin d'un Nième compte, pas besoin de s'emmerder a déployer une archi, quitte a se retrouver prisonnier d'une interface qui… disons, «force» une politique de développement.
Sur ce point, je préférais perso sourceforge: il était simple d'avoir des mailings lists publiques, ce qui impliquais donc que les contributeurs n'étaient pas traqués par le site.
Il y avait aussi des forums, bien plus simple d'accès aux béotiens, et bien d'autres fonctionnalités que GH est loin d'égaler a mes yeux.
Github appartient à Microsoft, qui le rentabilisera d'une façon ou d'une autre.
Lol.
Qui le rentabiliseras?
Ben oui, mais ou est le problème? L'open source, c'est pas juste du "hey, je paye 1) mon temps et 2) mon fric pour que vous puissiez utiliser mon logiciel! Et en plus, je fait la hotline gratos, et me fais insulter for fun!"
Pour info, la boîte derrière GH n'a jamais publié le code hein, ça n'a jamais rien eu à voir avec du libre.
Ils savent comment rentabiliser, et, en gros, le libre leur sers de pub gratos.
Tout comme ce que faisait sourceforge avant de perdre de la vitesse.
Sauf que, limite, sourceforge est plus libre: le soft d'origine est le même que celui utilisé par savannah. On a pas accès à l'histo de dev, certes, mais on a au moins accès a une partie de l'histoire (ça reste non libre selon moi).
Gitlab est sûrement ce que tu préférerais? C'est du libre en partie seulement.
Surtout ce qui est utilisé par leur forge publique et "gratuite".
Bitbucket?
Comme GH, et a une époque meilleure interface, mais ils ont choisi de la bloat, il faut maintenant plusieurs secondes avec un meilleurs hard et une meilleure connection pour charger chaque page.
Perso j'ai jamais aimé GH, mais je le trouve aujourd'hui plus supportable que la bouse qu'est devenue BB.
S'auto-héberger? T'auras moins de contributeurs, et en plus, faut gérer la technique (déployer une forge logicielle, se protéger contre les attaques, etc) et la loi (GPDR par exemple, mais aussi hadopi et bien d'autres).
Tous ces éléments combinés en font une menace pour l'avenir des logiciels libres. Certains projet sont bloqués sur Github, car leur historique et/ou leur encours de tickets n'est pas facile à migrer sur d'autres plateformes. Mais un "nouveau" (si on peut dire :-)) projet peut, devrait oserais-je dire, opter pour une alternative moins centralisée, monopolistique, aux mains du grand méchant crosoft.
Donne une seul argument réel de menace sur le libre, pour voir? git est, de base, décentralisé.
De nombreux (mais assez a mon goût) projets utilisent GH comme mirroir.
Au pire, même si tu ne me convaincs pas du mal que représentes GH (ça va être dur, je déteste déjà ce site), que proposes-tu?
Dis nous, comment faire?
Comment faire pour gratuitement exposer notre code a nous dev libristes sans mettre 2 ans a attendre l'approbation d'un quelconque projet?
Je t'écoutes, parce que je suis justement en train de monter mon propre serveur pour héberger mes projets perso. Qui n'auront pour seule interface de l'extérieur qu'un simple mail et un http(s) qui crache l'arbo du git.
[^] # Re: Une vraie alternative à LFS
Posté par freem . En réponse au journal Pourquoi j'ai installé Slackware ou la découverte du livre Débuter avec Linux. Évalué à 3.
Ce n'est pas identique, "curl | sh -" nécessite un effort de la part du fournisseur: il faut écrire un script shell.
Sinon, l'ancien triptyque "./configure && make && make install" ne s'applique qu'aux projets dépendants des autotools qui sont, je pense, en perte de vitesse (je dirais même que c'est pas plus mal! On est trolldi c'est donc permit)
[^] # Re: Boursorama banque
Posté par freem . En réponse au journal Quand la banque populaire force ses clients à manger des cookies. Évalué à 4.
Et comment tu fais le distinguo? Tu va lire chaque foutu cookie de tes sites bancaires et essayer de comprendre ce qui est écrit dedans toi?
[^] # Re: et si c'était ... l'évolution ?
Posté par freem . En réponse au journal Je fais partie d'une espèce menacée d'extinction. Évalué à 2.
Et a quel moment le patron est-il censé s'intéresser à l'équipe au juste?
[^] # Re: Solidaire dans la mouise
Posté par freem . En réponse au journal systemd, de pire en pire. Évalué à 3.
En gros, sur des machines que tu peux rattraper sans intervention coûteuse (le coût étant de diverses natures: argent, temps, réputation, etc) quand ça va merder.
Malheureusement, seuls les gens qui ont eu a gérer un parc de plus de 3 machines en plus d'autres tâches sont enclins a penser a ce genre de «détails» je le crains.
[^] # Re: azerty
Posté par freem . En réponse au journal systemd, de pire en pire. Évalué à 2.
Je suis intéressé par plus d'argumentation la dessus: pourquoi c'est pourri?
Accessoirement, ce n'est pas l'apanage de systemd, les daemontools le font aussi, et quand il faut interagir avec des systèmes (hard/soft) sur lesquels on n'a pas de maîtrise, ça sauve. Ou si on code de la merde aussi.
J'ai eu tous les cas :/
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3. Dernière modification le 17 juillet 2020 à 22:59.
C'est un fait, qui ne tente rien n'a rien, et pour une boîte, c'est sain de drop des projets pas rentables.
Mais on a accès au source et on peut host un instance pour refournir le service, pas avec google.
C'est, je pense la grande différence: Framasoft n'utilise en public que des logiciels libres (en privé, je sais pas) dont le code est accessible. Ce n'est pas le cas de google.
En fait, ça serait plus simple (pour moi) d'avoir un argument correct si les logiciels utilisés par Framasoft étaient sous affero, mais vu que je suis déjà pas fan de la GPL, je vais pas le demander.
Je suppose qu'un résumé possible est: «Moi, Freem, ai une certaine confiance dans le fait que Framasoft n'utilise que des logiciels dont je peux avoir le source pour les services dont je dépend, confiance que je n'accorde point a Google.»
Ce qui indique clairement que j'ai jamais été vérifier. Du coup.
Par contre, moi, je suis un utilisateur et un peu contributeur de LL, je n'utilise pas le LL juste parce que c'est souvent gratos. Enfin, ce n'est plus le cas.
Je suis sûr que la majeure partie des râleries contre google sont liées a ça.
Et que s'il y en a peu pour framasoft, c'est parce que c'est peu connu, hors de «notre sphère idéologique».
[^] # Re: Sans vouloir te vexer...
Posté par freem . En réponse au journal Quand la banque populaire force ses clients à manger des cookies. Évalué à 7.
J'ai pu tester ou voir les banques suivantes :
Interface de merde. Force l'usage de la souris par clavier stupide. C'est une des raisons pour lesquelles je me ferais un plaisir de les envoyer chier dès que je prévois un gros emprunt (maison). Perso, suis prêt a payer pour ne pas avoir cette merde, mais faudrait une garantie que ça dure…
Tiens, ben, le CA aussi dis… et c'est horrible a utiliser sur PC. Je suis pas le seul a m'en plaindre, mes parents aussi (oui, chez nous, on a tendance a ça, suivre ce qu'on nous a définit dans l'enfance tant qu'il n'y a pas d'intérêt manifeste a changer). Compte tenu de ma parenthèse, ça commence a peser sévère sur les raisons de changer!!
Merci d'aller voir csv aussi. Et 0 raison de pas le faire, ce dernier est importable et exportable par tous les outils que j'ai pu utiliser jusqu'a présent, ce qui est loin d'être limité à Excel et Calc, mais les inclue!
[^] # Re: Sans vouloir te vexer...
Posté par freem . En réponse au journal Quand la banque populaire force ses clients à manger des cookies. Évalué à 2.
Ce qui serait pour le coup l'argument le plus convainquant que j'ai vu en faveur des cryptomonnaies…
[^] # Re: but why ?
Posté par freem . En réponse au journal Quand la banque populaire force ses clients à manger des cookies. Évalué à 7.
Bah, d'un autre côté, les bronzonizations sont vachement moins intéressantes que ce message, et personne leur dit d'aller coller ça dans les liens.
Bon, accessoirement, un lien ne permets pas un titre assez long pour dire ce qu'on pense du lien. Et, du coup, perso, j'aime pas les liens. D'ailleurs, y'a rarement des commentaires, et c'est encore pire pour les échanges réels.
Il n'y est pas non plus possible de demander des alternatives (certes, ça aurait plus ça place dans les forums, mais vu qu'il y a annonce aussi, peut-être pas tant que ça?).
[^] # Re: oubli
Posté par freem . En réponse au journal quick start pour coco/R. Évalué à 2.
Exact, j'avais oublié.
[^] # Re: Merci !
Posté par freem . En réponse au journal quick start pour coco/R. Évalué à 2. Dernière modification le 16 juillet 2020 à 21:51.
Il y a 3 langages supportés, et vu le code je pense qu'il ne devrais pas être trop difficile de porter la bête pour un autre langage si la syntaxe dérive du C et que l'orienté objet est supporté.
Pour du python par contre, ça risque d'être plus chiant, mais je suis pas expert.
Et pour l'effort de rédaction, je vais juste profiter de mon propre journal pour virer mes notes locales, ça a mis du propre et ça m'a permis de régler un bug dans l'exemple du coup j'y gagne aussi :)
Par contre j'adorerais avoir un contre exemple de la même syntaxe avec d'autres outils.
[^] # Re: oubli
Posté par freem . En réponse au journal quick start pour coco/R. Évalué à 3.
franchement c'est honnête je trouve:
bon, c'est surtout que mon fichier de règles ici est bien trop trivial hein. Avec des règles plus complexes et surtout plus complètes c'est mieux.
Il aurait suffit que je change la production argv en
argv = identifier { option } '\n'pour avoir:J'ai vu des messages d'erreurs plus sympas lors de mes essais (qui sont sur un «langage» plus évolué), et ce, alors même que j'ai éludé la question de la gestion des erreurs.
# oubli
Posté par freem . En réponse au journal quick start pour coco/R. Évalué à 4.
Zut, j'ai oublié de préciser quelques détails au sujet des fichiers
.framefournis par l'upstream:clang --analyzedétecte un bugdos2unixsur les fichiers.framerésout le problème à la sourceConcernant mes patchs perso:
correctif du bug (je pense que c'est le seul patch vraiment important):
Mon log actuel (je pousserais sûrement upstream (dommage qu'ils aient pas importé l'historique quand même) quand j'aurai un peu plus de connaissance sur le code de base):
[^] # Re: Quand faut y aller, faut y aller !
Posté par freem . En réponse au message compiler-compiler: des suggestions?. Évalué à 2. Dernière modification le 16 juillet 2020 à 18:28.
C'est sûr. Et au pire, ça m'a permis de revérifier certains points, d'éclaircir mes notes, et ça me resservira peut-être quand je ne serais pas sur ma machine ou qu'il me faudra expliquer comment ça marche a un collègue (ça m'est déjà arrivé avec des journaux précédents).
[^] # Re: Quand faut y aller, faut y aller !
Posté par freem . En réponse au message compiler-compiler: des suggestions?. Évalué à 2.
C'est juste que j'aurai aimé avoir plus de recul sur le sujet (que je ne maîtrise pas du tout), mais bon, comme tu dis, il n'y a que 24H par jour :)
En plus, pas impossible qu'il y ait justement de quoi compléter mes notions dans les commentaires.
[^] # Re: Quand faut y aller, faut y aller !
Posté par freem . En réponse au message compiler-compiler: des suggestions?. Évalué à 3.
Pas vraiment, j'ai pas creusé bison/yacc, juste testé flex vite fait. M'enfin ouai, vais probablement gribouiller un truc dans la journée.
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
De mémoire, le but était de mieux toucher les gens qui se baladent juste sur le web, au détriment de la partie de leurs utilisateurs qui considèrent qu'un album est un tout.
Fait bien longtemps que j'y suis pas allé pour le coup. Ni sur dogmazic d'ailleurs.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
C'est valable pour toutes les forges ça, le fait de pas pouvoir migrer les tickets par exemple (c'est la 2nd plus grosse fonctionnalité d'une forge après tout).
La seule solution au final, c'est d'embarquer les tickets dans le repo. De ce point de vue, fossil est très intéressant. Le problème, c'est juste qu'il faut apprendre a utiliser un nouvel outil, ce qui va freiner les premières contributions de la majorité des contributeurs.
Pour les autres DVCS (et notamment git), il existe divers projets pour ça, mais même si j'aime énormément l'idée (bien plus que de devoir me taper l'UI de github, tu peux me croire), je garde mes doutes sur les implémentations (par exemple, devoir installer la pile ruby pour ça me gêne énormément).
Il faudrait que je reprenne un peu le temps de regarder d'ailleurs.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
Il est quand même moins probable que, par exemple, google oublie de payer son domaine que toi ou moi. Ou que leur compte bancaire soit fermé suite a bronsonisation du propriétaire.
Pour le fait de leur politique, c'est clairement un fait, surtout pour google. D'ailleurs ils avaient leur propre forge pendant un temps, mais je pense que peu de monde avait vraiment envie d'héberger leur code chez eux, pour entre autres cette raison que tu cites.
D'une manière ou d'une autre, il n'y a vraiment que la réplication qui puisse freiner le problème de la disparition des sources.
[^] # Re: MADNESS
Posté par freem . En réponse au sondage et si c'était à refaire ?. Évalué à 2.
C'est un peu le but :)
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
Son évolution, ironiquement.
Le fait que ce soit maintenant impossible ou presque de faire des recherches par album.
Leur "nouveau" site est anti-ergonomique pour qui veut écouter un album, mais, j'accepte que c'est un choix.
Pour ce qui est de Dogmazic, en revanche, ça s'est amélioré, même si c'est toujours pas ça (c'est un peu de ma faute, je pourrais p'tet aider, même si je suis une bite ((ouai, c'est fait exprès pour rappeler que non, les références au mâle ne sont pas toujours positives)) en frontal).
Il faut dire que dogmazic est un site commercial, ils ont besoin de revenus, et c'est normal. Je ne leur en veux pas.
D'un autre côté, ni l'un ni l'autre ne suivent vraiment le libre, dans le sens ou il est rare que les sources (partitions, paroles, etc) soient fournies avec.
Il s'agit d'ailleurs d'un problème récurrent pour les gens qui font des jeux vidéo libres (je ne fais que contribuer): rares sont les ressources.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 3.
Pareil.
D'un autre côté, j'ai le même effet maintenant avec github en vrai, parce que j'ai tendance a caler mon patch dans (ou en pièce jointe à) la réponse, et a chaque fois, même si ça améliore les choses, il faut faire 20 aller-retours pour qu'il soit accepté, pour des questions de code-style (jamais documenté), qui auraient été plus rapidement patchées via un simple de l'auteur.
Pour moi, ce n'est pas que MS soit l'actuel proprio de GH le problème, le problème c'est la bureaucratie inhérence à la façon de gérer les projets par "push-request".
Ça ne date pas du rachat, hein.
Mais ça a toujours été plus proche de la cathédrale que du bazar sur lequel, notamment, linux et ses distributions sont bâties.
Et dans le cas des cathédrales, les BSDs ont prouvé qu'héberger sa forge est efficace, mais ce type de forges se basent sur les échanges de mails.
Je sais que je diverge du sujet initial, mais, la dépendance aux interfaces web je la vit assez mal perso, et toi?
[^] # Re: Diablo Swing Orchestra
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 2.
Han j'avais pas tilté!
Bien vu!
D'ailleurs, si tu as un remplaçant pour jamendo, voire un site ou je pourrais retrouver les artistes que j'y ai découvert, je suis preneur…
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 1. Dernière modification le 15 juillet 2020 à 20:45.
Et qu'en est-il de l'inverse?
De GL ou GH vers d'autres forges moins populaires?
Qu'en est-il aussi des raisons? Techniques? Une BDD c'est toujours chiant a migrer c'est évident, les logiciels sont pas conçus de la même manière…
Hein?
Et tu ne peux pas instancier ton instance gitlab chez toi sans faire tourner de code proprio. A moins que, et ça me surprendrais, l'instance publique ne fasse tourner que du code sous Affero GPL?
Ça s'appelle du bullshit chez moi. Moi, je suis un techie bas de gamme, je n'accepte que les arguments efficaces, mes parents ont oublié de m'installer le plugin pour regarder la marque avant de critiquer.
[^] # Re: (HS) Github
Posté par freem . En réponse à la dépêche Sortie de Cover Thumbnailer v0.10.0. Évalué à 4.
Ben, tout le monde a tapé sur Sourceforge (qui héberge cela dis toujours les gros fichiers de bien des projets dont le dev se fait sur GH ou GL hein…) donc on l'exclue.
Y'a quoi d'autre? GitLab? Pas monopole, certes, mais mais 100% libre non plus, leur plateforme n'utilise pas la version libre.
Au final, le but des utilisateurs de GH, c'est de réduire le taux d'emmerdement des nouveaux contributeurs et des développeurs.
Pas besoin d'un Nième compte, pas besoin de s'emmerder a déployer une archi, quitte a se retrouver prisonnier d'une interface qui… disons, «force» une politique de développement.
Sur ce point, je préférais perso sourceforge: il était simple d'avoir des mailings lists publiques, ce qui impliquais donc que les contributeurs n'étaient pas traqués par le site.
Il y avait aussi des forums, bien plus simple d'accès aux béotiens, et bien d'autres fonctionnalités que GH est loin d'égaler a mes yeux.
Lol.
Qui le rentabiliseras?
Ben oui, mais ou est le problème? L'open source, c'est pas juste du "hey, je paye 1) mon temps et 2) mon fric pour que vous puissiez utiliser mon logiciel! Et en plus, je fait la hotline gratos, et me fais insulter for fun!"
Pour info, la boîte derrière GH n'a jamais publié le code hein, ça n'a jamais rien eu à voir avec du libre.
Ils savent comment rentabiliser, et, en gros, le libre leur sers de pub gratos.
Tout comme ce que faisait sourceforge avant de perdre de la vitesse.
Sauf que, limite, sourceforge est plus libre: le soft d'origine est le même que celui utilisé par savannah. On a pas accès à l'histo de dev, certes, mais on a au moins accès a une partie de l'histoire (ça reste non libre selon moi).
Gitlab est sûrement ce que tu préférerais? C'est du libre en partie seulement.
Surtout ce qui est utilisé par leur forge publique et "gratuite".
Bitbucket?
Comme GH, et a une époque meilleure interface, mais ils ont choisi de la bloat, il faut maintenant plusieurs secondes avec un meilleurs hard et une meilleure connection pour charger chaque page.
Perso j'ai jamais aimé GH, mais je le trouve aujourd'hui plus supportable que la bouse qu'est devenue BB.
S'auto-héberger? T'auras moins de contributeurs, et en plus, faut gérer la technique (déployer une forge logicielle, se protéger contre les attaques, etc) et la loi (GPDR par exemple, mais aussi hadopi et bien d'autres).
SourceHut? Faut payer, ou s'auto-héberger.
Donne une seul argument réel de menace sur le libre, pour voir? git est, de base, décentralisé.
De nombreux (mais assez a mon goût) projets utilisent GH comme mirroir.
Au pire, même si tu ne me convaincs pas du mal que représentes GH (ça va être dur, je déteste déjà ce site), que proposes-tu?
Dis nous, comment faire?
Comment faire pour gratuitement exposer notre code a nous dev libristes sans mettre 2 ans a attendre l'approbation d'un quelconque projet?
Je t'écoutes, parce que je suis justement en train de monter mon propre serveur pour héberger mes projets perso. Qui n'auront pour seule interface de l'extérieur qu'un simple mail et un http(s) qui crache l'arbo du git.