Je n'utilise bash que sous la contrainte, mais dans ce genre de cas j'apporte les options suivantes :
autocd : permet de se déplacer en indiquant le dossier sans cd ($OLDPWD équivaut alors à cd -)
globstar : permet d'avoir des globbings plus évolués comme le fameux ** pour être récursif (mv ~/**/*.pdf /dest/)
histappend : améliore la gestion de l'historique quand on a plusieurs shell de lancé (c'est pas parfait, mais c'est moins pire que ce qui est fait de base)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'ai répondu à une question qui demandait aux non-utilisateurs de systemd d'expliquer les motivations de leur choix.
Non, il demande ce qui freine l'utilisation de systemd. Il demande pas à n'importe qui son avis. Il demande quels sont les points techniques qui posent problèmes dans systemd. Ma mère n'utilise pas systemd, la question ne lui est pas pour autant adressée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Ce que je dis c'est que pour arriver au même niveau de fonctionnalité que les inits historiques qui sont toujours utilisé ce n'est pas la mère à boire.
Oui tu peux déployer des trésors de sophistications pour couvrir un tas de fonctionnalités toujours plus pointue.
Mais mon point c'est de dire que remplacer sysvinit/rc.d n'est pas particulièrement compliqué puisqu'ils couvrent très peu de besoin par eux-même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Être proactif est généralement une mauvaise idée c'est ça ?
j'ai dit ça ?
Tu as raison, je reformule :
Être proactif c'est pour les autres, c'est ça ?
Si c'est quelque chose dont tu as besoin (suffisamment pour te renseigner, pour savoir ce que ça t'apporte ou pas, etc) être proactif est généralement une bonne idée. Comme dans tous les métiers techniques, choisir volontairement d'ignorer une nouveauté qui a une grosse probabilité de t'arriver est une faute importante. Il y en a qui font faillite sur ce genre de bêtise.
Si tu n'es qu'un simple utilisateur, ton avis est celui d'un simple utilisateur. Tu ne vois pas l'intérêt parce que tu te contente de lancer/arrêter les services de ta distribution et alors, ben on s'en fout parce que tout le boulot est déjà fait pour toi. Tu pourra toujours continuer de lancer la commande service tu ne verra qu'un changement de ce qu'elle renvoie. Mais globalement on s'en fout vraiment (comme on s'en fou de mon avis sur la manière d'envoyer quelque chose sur Mars par exemple, c'est pas mon domaine).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Donc l'avantage de systemd réside dans la facilité d'inclusion des logiciels dans un maximum de distribution en minimisant les efforts à fournir par leurs auteurs.
Un des intérêts. Franchement tu troll si tu ne vois pas la liste des autres intérêts. Tu as pleins de trucs par là à ce sujet : https://linuxfr.org/tags/systemd/public tu y trouvera tous les pour et les contre.
En l'état, le jour où je n'aurai plus le choix parce que les mainteneurs de distribution auront décidé qu'ils en ont assez de maintenir en parallèle un outil facilitant leur vie et un outil qu'ils considèrent comme un poids mort ne servant qu'à un chouilla d'utilisateurs accrochés à leur fossile, alors je migrerai.
Être proactif est généralement une mauvaise idée c'est ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
le ton un peu « suivez-nous ou mourrez » du projet
Quand je vois que quasiment toutes les distrib sont passées à systemd c'est soit que les mainteneurs sont juste des nazes à qui on peut dire ça et qu'ils ne peuvent pas choisir, soit que ça répond à des problèmes qu'ils avaient.
Je parle de communication.
Un système d'init c'est assez bidon, il en existe au moins une dizaine c'est une bonne preuve que ce n'est pas d'une difficulté incroyable à créer.
Hum, ça je n'en mettrais pas ma main à couper tout de même…
Regarde les arcanes de sysvinit ou le rc de NetBSD (je ne sais pas les différences qu'il y a sur les autres BSD), c'est pas vraiment pas incroyable. Cette simplicité est même certaine fierté face à la sophistication d'upstart/systemd. On a tourné des dizaines d'années avec ces choses relativement triviales.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'ai toujours pas compris quel était le problème de systemd…
Systemd vient avec une approche assez disruptive. Il bouge les lignes et fait beaucoup de choses (systemd, logind,…).
De plus il a un petit mode « bazars » plutôt que « cathédrale » (le fait de ne plus se baser sur une séquence prédéfinie de services à lancer).
Tout ça plus les problèmes de communication (le ton un peu « suivez-nous ou mourrez » du projet, les news en mode « bouh ! Ils ont un bug ! C'est trop nul systemd ! »,…) explique très bien le coté clivant du projet.
Bref, à part un côté "je veux pas changer ce qui marchote" c'est quoi le vrai problème ?
Il n'y a pas de vrai problème. Un système d'init c'est assez bidon, il en existe au moins une dizaine c'est une bonne preuve que ce n'est pas d'une difficulté incroyable à créer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
de par sa nature, il bénéficie de pas mal d’attention de la part de cryptologues et de chercheurs en sécurité
C'est ce que l'on se serait dit d'OpenSSL et on sait ce qu'il en était finalement. D'ailleurs je présume que cette histoire a mis un coup de fouet à tout ces logiciels orientés sécurité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Le seul cas d’usage non-tordu qui me vient à l’esprit, où tu pourrais avoir deux clefs associées à la même adresse, est le cas d’un changement de clef, où pendant une certaine période ton ancienne clef et ta nouvelle cohabitent dans ton trousseau.
Dans un contexte autre que le chiffrement de fichier (ou de mail), j'utilise plusieurs clefs pour une même identité pour me connecter en ssh (et par extension à des serveurs git). L'intérêt est d'avoir une clef privée par poste de travail et en cas de problème (vol, intrusion,…) de simplement désavouer cette clef.
Je ne sais pas si ça peut avoir du sens avec GPG.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je suis conscient que la violence dans le fond se voit moins que la violence dans la forme[…]
Non quand tu pose pamphlet à l'encontre des « libristes/communauté du libre/je ne sais quel autre groupe pas très précis ». C'est le même genre de violence que ce que tu viens de subir (tu veux une cellule psychologique ?). C'est du même acabit sauf que tes propos sont souvent plus violent et que pour toi on sait très bien que tu sais ce que tu fais, tu sais où tu va. C'est tout à fait volontaire (il y a récidive alors que ça t'a était dis déjà plusieurs fois).
Il est vraiment tard pour te la jouer victime larmoyante je trouve.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Désolé, mais je prend très mal (enfin, version café du coin) quand on me considère comme inexistant juste parce que je suis une entreprise qui fait du libre.
"le mode décentralisé de git convient très bien à l'open source, celui simple de svn est bien plus facile à mettre en œuvre dans une boîte" ne te dérange pas, OK, mais désolé c'est sur ça que tu devrais réagir, car c'est justement ces gros préjugés transmis sous couvert de simplification qui font du mal au libre.
Pauvre chou… Tu te rend compte que tu en fait des beaucoup plus violente que ça à longueur de commentaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Quand même de moins en moins (surtout en pourcentage).
Tu as des chiffres ? Peut être, hein ? Moi j'aime bien et là où je suis actuellement on a un github, mais tout ce que j'ai pu voir avant c'était du redmine à tout les étages et ça n'a rien de fais à la va vite.
Je préfère quasiment tout à la gestion de ticket de github par exemple.
Je suis pas fan du wiki de github, c'est cool de pouvoir le récupérer avec git, mais quand tu as joué avec xwiki tu fais forcément la gueule.
La CI je ne sais pas trop ce que ça a avoir puisque ni github ni gitlab n'en font à ce que je sache. Les gens utilisent travis ou codeship par exemple. Jenkins fait vraiment très bien le boulot surtout depuis la version 2.
La gestion des livrable ? Tu veux vraiment aborder la question de la gestion des livrables de github, parce qu'elle a un certain passif quand même ?
Github est bien (et gitlab aussi je présume), je dis pas le contraire, mais je vois pas en quoi d'autres solutions ne sont pas à minima aussi bien.
Et du coup je ne vois pas en quoi répondre à quelqu'un qui demande un truc d'utiliser forcément tout le packaging et de le considérer comme un débile s'il ne le fait pas est intelligent…
Un gestionnaire de version moderne doit gérer du CI (par gérer j'entends quelques tests avant d'accepter le PR), sinon il y a un problème de suivi de qualité / non régression (au moins dans la possibilité).
Ou l'inverse, tu peux très bien avoir ta CI qui gère ton gestionnaire de version. Jenkins fait ça très bien. Il se connecte à ton dépôt git et va lancer un build pour toutes tes branches et tu peux lui faire faire pour les pull request sans soucis.
Vraiment, il existe d'autres choses que gitlab, ne restez pas coincé dans des idées aussi coincées.
Je rappel, s'il le faut que pendant longtemps (je ne sais pas si c'est toujours le cas aujourd'hui), mais le créateur de git n'aimait pas du tout le fonctionnement de github (et celui de gitlab par extension).
Il y a des gens qui font autrement, écoutez un peu avant de juger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
J'ai pas dis que c'était utile. Je dis juste que ce n'est pas une réponse adaptée.
Quand tu va voir ton garagiste pour faire changer d'amortisseur, il te change aussi la courroie parce que c'est quand même mieux ?
Il a peut être déjà tout ce qu'il faut pour le reste, hein ? Il existe des gens qui vivent hors de github/gitlab et qui font les choses au moins aussi bien que toi. Arrête de les prendre de haut.
Avoir un redmine, un jenkins et un reviewboard c'est très classique par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Il est toujours possible d'utiliser git (ou mercurial) comme client SVN.
Il est aussi possible de faire tout ça avec SVK.
Si, d'un point de vu organisation, on reste sur SVN autant avoir un serveur SVN. L'utilisation d'un git/hg en local permet de se mettre le pied à l'étrier au fil de l'eau sans obliger toute l'équipe à faire le switch.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Pour les gros projets je demande à voir, et parce que ça n'apporte qu'un des aspects que couvre gitlab, comme le mécanisme de merge request, les review, le bugtracker, la CI…
Qui à part ceux qui ont dit qu'il fallait utiliser git(hub|lab) a parlé de review, de CI ou de bugtracking par exemple ?
Je peux aussi te dire qu'il faut utiliser attlassian parce qu'ils font aussi le board kanban, le burndown, une gestion de fichiers, que ça fait les SLA sur les tickets,… Mais en quoi c'est utile pour le gars qui veut un gestionnaire de version ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Personne ne t'oblige à réutiliser du code GPL, aucun soucis.
Personne ne t'oblige à réutiliser du code breveté, aucun soucis.
Le droit d'auteur est sur le code, pas sur un artefact généré par du code.
Cette distinction est un détail d'implémentation. Si ton outil c'est du shell, il n'y a pas de distinction, si c'est du python tu peux avoir du code généré, du code généré au runtime, pas de génération du tout,… Si je lance ton code C en GPL avec tcc, c'est ou outil ou pas ?
Du coup ça se passe comment si j'utilise ton .so sans utiliser ton .h ?
Il est impossible de faire un produit dérivé (au sens légal) entre du code généré, et un autre code.
Qu'est-ce qui caractérise la chose ? Parce que j'ai vachement l'impression que du coup une API WS (ou AMQP ou TCP je suis pas sectaire, hein ?) c'est lié au code généré, alors que la dépendance à une interface programmatique est elle lié au code sous licence GPL. Bref j'ai l'impression de revenir sur l'hypothèse que j'avais en tête au départ.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Uniquement si tu raisonnes comme un mec qui veut baiser la GPL, le principe de développement du soft, et les développeurs du code, qui demandent uniquement que les utilisateurs jouent le jeu.
Ah ah ! D'un coup on devient violent (au moins dans le verbiage) :
le principe de contamination me semble proche, ce n'est pas une question de faire l'amour à qui que ce soit
je raisonne en temps que quelqu'un qui ne tiens pas à écrire du code sous une licence qu'il ne comprends pas (c'est mon cas apparemment…)
et uniquement d'un code, pas d'un outil
Quel est la différence ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
Je ne suis pas un utilisateurs de Winwin, mais je sais qu'il y a chocolatey, wapt et d'autres. Chocolatey sort du lot où ça en est un parmis tant d'autres ? Je dis ça parce que ce serait une bonne nouvelle qu'il y en ai un qui se démarque.
LibO n'est pas dans le store de MS ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Ma config de bash
Posté par barmic . En réponse au journal Des "basheries". Évalué à 6.
Je n'utilise bash que sous la contrainte, mais dans ce genre de cas j'apporte les options suivantes :
cd($OLDPWDéquivaut alors àcd -)**pour être récursif (mv ~/**/*.pdf /dest/)Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: bypasser un alias
Posté par barmic . En réponse au journal Des "basheries". Évalué à 6.
Et moi :
Parce que bon les sécurités c'est pour les autres.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: tweet ?
Posté par barmic . En réponse à la dépêche Conférence LinuxFr(.org), mais refaire ?. Évalué à 3.
C'est quoi une information complète ? Par exemple : https://linuxfr.org/users/rodhlann/journaux/des-basheries est très incomplet. La page man de bash montre bien plus de choses (et elle ne montre pas tout).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 8.
Non, il demande ce qui freine l'utilisation de systemd. Il demande pas à n'importe qui son avis. Il demande quels sont les points techniques qui posent problèmes dans systemd. Ma mère n'utilise pas systemd, la question ne lui est pas pour autant adressée.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 1.
Ce que je dis c'est que pour arriver au même niveau de fonctionnalité que les inits historiques qui sont toujours utilisé ce n'est pas la mère à boire.
Oui tu peux déployer des trésors de sophistications pour couvrir un tas de fonctionnalités toujours plus pointue.
Mais mon point c'est de dire que remplacer sysvinit/rc.d n'est pas particulièrement compliqué puisqu'ils couvrent très peu de besoin par eux-même.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 7.
Tu as raison, je reformule :
Si c'est quelque chose dont tu as besoin (suffisamment pour te renseigner, pour savoir ce que ça t'apporte ou pas, etc) être proactif est généralement une bonne idée. Comme dans tous les métiers techniques, choisir volontairement d'ignorer une nouveauté qui a une grosse probabilité de t'arriver est une faute importante. Il y en a qui font faillite sur ce genre de bêtise.
Si tu n'es qu'un simple utilisateur, ton avis est celui d'un simple utilisateur. Tu ne vois pas l'intérêt parce que tu te contente de lancer/arrêter les services de ta distribution et alors, ben on s'en fout parce que tout le boulot est déjà fait pour toi. Tu pourra toujours continuer de lancer la commande service tu ne verra qu'un changement de ce qu'elle renvoie. Mais globalement on s'en fout vraiment (comme on s'en fou de mon avis sur la manière d'envoyer quelque chose sur Mars par exemple, c'est pas mon domaine).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 3.
Un des intérêts. Franchement tu troll si tu ne vois pas la liste des autres intérêts. Tu as pleins de trucs par là à ce sujet : https://linuxfr.org/tags/systemd/public tu y trouvera tous les pour et les contre.
Être proactif est généralement une mauvaise idée c'est ça ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 10.
Je parle de communication.
Regarde les arcanes de sysvinit ou le rc de NetBSD (je ne sais pas les différences qu'il y a sur les autres BSD), c'est pas vraiment pas incroyable. Cette simplicité est même certaine fierté face à la sophistication d'upstart/systemd. On a tourné des dizaines d'années avec ces choses relativement triviales.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: systemd
Posté par barmic . En réponse au journal Devuan a deux ans . Évalué à 7.
Systemd vient avec une approche assez disruptive. Il bouge les lignes et fait beaucoup de choses (systemd, logind,…).
De plus il a un petit mode « bazars » plutôt que « cathédrale » (le fait de ne plus se baser sur une séquence prédéfinie de services à lancer).
Tout ça plus les problèmes de communication (le ton un peu « suivez-nous ou mourrez » du projet, les news en mode « bouh ! Ils ont un bug ! C'est trop nul systemd ! »,…) explique très bien le coté clivant du projet.
Il n'y a pas de vrai problème. Un système d'init c'est assez bidon, il en existe au moins une dizaine c'est une bonne preuve que ce n'est pas d'une difficulté incroyable à créer.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: prédictibilité et confiance
Posté par barmic . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 4.
C'est ce que l'on se serait dit d'OpenSSL et on sait ce qu'il en était finalement. D'ailleurs je présume que cette histoire a mis un coup de fouet à tout ces logiciels orientés sécurité.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: La politique ask.
Posté par barmic . En réponse au journal De la confiance dans le monde OpenPGP. Évalué à 4.
Dans un contexte autre que le chiffrement de fichier (ou de mail), j'utilise plusieurs clefs pour une même identité pour me connecter en ssh (et par extension à des serveurs git). L'intérêt est d'avoir une clef privée par poste de travail et en cas de problème (vol, intrusion,…) de simplement désavouer cette clef.
Je ne sais pas si ça peut avoir du sens avec GPG.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Et les autres
Posté par barmic . En réponse au journal Programmer ça craint. Évalué à 4.
On sait faire des mises à jours sans rupture de service :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Non quand tu pose pamphlet à l'encontre des « libristes/communauté du libre/je ne sais quel autre groupe pas très précis ». C'est le même genre de violence que ce que tu viens de subir (tu veux une cellule psychologique ?). C'est du même acabit sauf que tes propos sont souvent plus violent et que pour toi on sait très bien que tu sais ce que tu fais, tu sais où tu va. C'est tout à fait volontaire (il y a récidive alors que ça t'a était dis déjà plusieurs fois).
Il est vraiment tard pour te la jouer victime larmoyante je trouve.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Ce qui est je trouve pourri comme réaction, c'est que personne n'en sait rien, mais que ça n'empêche pas de présumer, puis de juger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Ce fut difficile à sortir !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -1.
Pauvre chou… Tu te rend compte que tu en fait des beaucoup plus violente que ça à longueur de commentaire ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.
Tu as des chiffres ? Peut être, hein ? Moi j'aime bien et là où je suis actuellement on a un github, mais tout ce que j'ai pu voir avant c'était du redmine à tout les étages et ça n'a rien de fais à la va vite.
Je préfère quasiment tout à la gestion de ticket de github par exemple.
Je suis pas fan du wiki de github, c'est cool de pouvoir le récupérer avec git, mais quand tu as joué avec xwiki tu fais forcément la gueule.
La CI je ne sais pas trop ce que ça a avoir puisque ni github ni gitlab n'en font à ce que je sache. Les gens utilisent travis ou codeship par exemple. Jenkins fait vraiment très bien le boulot surtout depuis la version 2.
La gestion des livrable ? Tu veux vraiment aborder la question de la gestion des livrables de github, parce qu'elle a un certain passif quand même ?
Github est bien (et gitlab aussi je présume), je dis pas le contraire, mais je vois pas en quoi d'autres solutions ne sont pas à minima aussi bien.
Et du coup je ne vois pas en quoi répondre à quelqu'un qui demande un truc d'utiliser forcément tout le packaging et de le considérer comme un débile s'il ne le fait pas est intelligent…
Pour conclure je citerais un grand mouleur⋅
« Passons… »
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: git != svn
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 0.
BIM ! Comme c'est envoyé ! Tu dois être content après une réflexion comme ça ! Aller taper sur les gens avant le week-end ça doit être cool !
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 6.
Ou l'inverse, tu peux très bien avoir ta CI qui gère ton gestionnaire de version. Jenkins fait ça très bien. Il se connecte à ton dépôt git et va lancer un build pour toutes tes branches et tu peux lui faire faire pour les pull request sans soucis.
Vraiment, il existe d'autres choses que gitlab, ne restez pas coincé dans des idées aussi coincées.
Je rappel, s'il le faut que pendant longtemps (je ne sais pas si c'est toujours le cas aujourd'hui), mais le créateur de git n'aimait pas du tout le fonctionnement de github (et celui de gitlab par extension).
Il y a des gens qui font autrement, écoutez un peu avant de juger.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.
J'ai pas dis que c'était utile. Je dis juste que ce n'est pas une réponse adaptée.
Quand tu va voir ton garagiste pour faire changer d'amortisseur, il te change aussi la courroie parce que c'est quand même mieux ?
Il a peut être déjà tout ce qu'il faut pour le reste, hein ? Il existe des gens qui vivent hors de github/gitlab et qui font les choses au moins aussi bien que toi. Arrête de les prendre de haut.
Avoir un redmine, un jenkins et un reviewboard c'est très classique par exemple.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: ce n'est pas un problème d'outillage
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
Il est toujours possible d'utiliser git (ou mercurial) comme client SVN.
Il est aussi possible de faire tout ça avec SVK.
Si, d'un point de vu organisation, on reste sur SVN autant avoir un serveur SVN. L'utilisation d'un git/hg en local permet de se mettre le pied à l'étrier au fil de l'eau sans obliger toute l'équipe à faire le switch.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par barmic . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2.
Qui à part ceux qui ont dit qu'il fallait utiliser git(hub|lab) a parlé de review, de CI ou de bugtracking par exemple ?
Je peux aussi te dire qu'il faut utiliser attlassian parce qu'ils font aussi le board kanban, le burndown, une gestion de fichiers, que ça fait les SLA sur les tickets,… Mais en quoi c'est utile pour le gars qui veut un gestionnaire de version ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ha les intégristes du libre...
Posté par barmic . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 4.
Personne ne t'oblige à réutiliser du code breveté, aucun soucis.
Cette distinction est un détail d'implémentation. Si ton outil c'est du shell, il n'y a pas de distinction, si c'est du python tu peux avoir du code généré, du code généré au runtime, pas de génération du tout,… Si je lance ton code C en GPL avec tcc, c'est ou outil ou pas ?
Du coup ça se passe comment si j'utilise ton .so sans utiliser ton .h ?
Qu'est-ce qui caractérise la chose ? Parce que j'ai vachement l'impression que du coup une API WS (ou AMQP ou TCP je suis pas sectaire, hein ?) c'est lié au code généré, alors que la dépendance à une interface programmatique est elle lié au code sous licence GPL. Bref j'ai l'impression de revenir sur l'hypothèse que j'avais en tête au départ.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Ha les intégristes du libre...
Posté par barmic . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à 0.
Ah ah ! D'un coup on devient violent (au moins dans le verbiage) :
Quel est la différence ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Mise à jour intégrée ?
Posté par barmic . En réponse à la dépêche LibreOffice : de 5.0 à 5.2, un an après. Évalué à 3.
Je ne suis pas un utilisateurs de Winwin, mais je sais qu'il y a chocolatey, wapt et d'autres. Chocolatey sort du lot où ça en est un parmis tant d'autres ? Je dis ça parce que ce serait une bonne nouvelle qu'il y en ai un qui se démarque.
LibO n'est pas dans le store de MS ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)