Un warez est contre la volonté de l'auteur.
Ton exemple respecte la volonté de l'auteur.
rien de nouveau, ce qui est vendu est le "nom", la facilité, surtout l'affichage au chef qui ne cherchera pas plus (de tête libcrypto fait plus fort avec du domaine publique mais tu peux aussi acheter une licence)
au passage ici tu fais la pub de l'alternative légale, du coup tu enlèveras potentiellement des sous à l'upstream. Voulu?
Tout à fait, et j'ai oublié de le préciser.
L'attaque était en partie sur le code "pour Internet", et le protocole Internet parfait les français l'ont fait (ATM, ça allait tout déchirer tellement on avait conçu un bon truc et qu'on avait pensé à tout avec des contrats entre tout les acteurs, enfin tout sauf le coût) et personne ne l'a utilisé, car justement 1% de merde pour Internet est parfaitement acceptable (d'autres l'ont compris et on fait cette "merde" d'IP et d'Ethernet, quoi est utilisé de nos jours?), ce n'est pas un parachute (et si c'est important, tu utilises pas Internet mais un autre truc plus cher et tu es prêt à payer pour).
Tout est question de compromis, la recherche du code parfait n'est pas mieux que de faire trop de code pourri (les deux extrêmes sont pourris). C'est disons amusant de voir une non nouveauté d'attaque contre du "code pourri", je dois me faire vieux mais l'histoire se répète sur les critiques "prenant conscience du niveau du bordel" :), n’empêche à la fin ce n'est jamais le code parfait qui gagne (spoiler: c'est le code qui est un compromis entre fonctionnalités et bugs pour un coût donné).
Bref, une fois n'est pas coutume, on est parfaitement en phase et j'avais oublié cette partie dans ma tirade, merci de le rappeler.
"À FAIRE : CORRIGER ÇA, C'EST SUPER URGENT" écrits il y a dix ans.
Tiens, quelqu'un a lu mon code!
Je ne sais pas si ça fait du bien de savoir que je ne suis pas seule à désespérer face à certains travaux ubuesques, ou si, au contraire, je ne suis pas plus inquiète en prenant conscience du niveau du bordel.
C'est un peu facile.
Perso, je le vois autrement : il vaut mieux du code qui marchote en faisant ce qu'on lui demande dans 99% des cas que du code "parfait" qui fait quasi-rien et donc que personne ne veut (ni utiliser ni payer).
Et si tu as peur, pas de soucis pour recevoir ton argent (10x plus que pour le code qui marchote) pour corriger tout ça, sinon bon ça reste de la théorie : ça ne t’intéresse pas vraiment, sorti du bar du coin, un peu comme les anti-nucléaires toujours chez EDF pour leur électricité (anti, mais sans être prêt à dépenser même pas 10% de plus pour leur convictions, faut pas déconner).
Ca me fait penser à Hurd contre Linux, je préfère le Linux buggué utilisable au Hurd "parfait" inutilisable.
Bref, l'attaque est un peu facile, comme toujours c'est une question de compromis (il ne faut pas non plus que ce soit des trous de sécurité béants diffusés à grande échelle et qui permettent de faire tomber Dyn qui lui doit se taper les conséquences, mais "désespérer" tant que ce n'est pas parfait ne changera pas le monde).
Bon après, je n'ai pas été convaincu par l'humour du texte, ça ne doit pas aider. Va falloir beaucoup plus (cohérent, constructif et réaliste, chiffré genre tu es prête à payer combien en plus pour calmer ton inquiétude ou combien gagnerait le peuple dans son ensemble si on forçait par la loi certains critères dont on a aussi chiffré le coût) pour changer les esprits.
Autant ça me parait normal que ce soit le bazar dans notre cathédrale, parce qu'on est nombreux à bidouiller "pour voir", "pour se former", "pour s'amuser" et surtout sans être payé et donc bon, si ce n’est pas parfait, on a des excuses…
Pas compris de quoi tu parles, entreprise ou perso ne change rien au sujet (comme l'open source / libre n'est pas réservé au perso), et tu sembles associer "sans être payé" à quelque chose qui est réducteur (je ne sais pas exactement quoi, mais tout ce que j'imagine est une réduction de la réalité).
(et oui je me sens un peu attaqué gratuitement en tant que développeur, donc je réagis)
euh…
(et pour le pic sur les idées, c'est quand même bizarre je dis souvent que je sais que je ne fais pas tout parfaitement : désolé, je fais la différence entre ce que je fais et ce qui serait le mieux à faire, est-ce difficile à faire cette différence? Ici par exemple je pourrai très bien ne pas être passé à Git et le conseiller quand même car je sais que je ne suis pas sur le "bon chemin". J'ai l'impression qu'il y a une grosse difficulté à accepter qu'une personne puisse faire la différence entre ce qu'elle fait et ce qu'elle devrait faire, et l'impression que pas mal de monde doit défendre absolument sa façon de faire comme la meilleure car il fait comme ci comme ça sans se dire qu'il faudrait changer, l'impression n'est pas que dans ce journal).
Je pensais benoîtement que SVN ayant moins de fonctionnalité (mais là encore je dis peut-être une connerie) il était plus rapide à prendre en main.
Pour le même usage, ce n'est pas parce qu'un outil permet plus qu'il est plus compliqué qu'un outil plus simple.
C'est un préjugé classique que d'imaginer que puissant veut dire complexe dans tous les cas (préjugé aussi pour les développeurs qui pour un usage simple vont dire "oui c'est plus compliqué que le concurrent mais c'est parce qu'on propose plus de choses", mauvais développeur qui légitime son incompétence en design par une fausse excuse).
Bref : Oui est (très) compliqué pour des choses assez compliquées que SVN ne permet pas. Mais pour des choses "à la SVN" c'est kif kif pour qui n'a jamais touché à un gestionnaire de version (il ne trouvera pas que commiter en local puis pusher est plus compliqué, il trouvera pas mal de pouvoir commiter dans l'avion et pusher en y sortant, et pétera un câble quand on le forcera à utiliser SVN et que sa connexion Internet a sauté et que donc il peut même pas faire 2-3 commit en attendant, bref les gens hurlent aux manques en se basant sur ce qu'ils ont utilisé en premier).
j'ai un ton méprisant qui fait un peu grosse-boîte-sérieuse-costard-cravate contre petite-boîte-de-merde-qui-fait-du-libre. Ça n'était pas mon intention (c'en est même à l'opposé) et j'en suis vraiment désolé.
Apprécié.
Mais juste je reprécise : ça n'a vraiment rien à voir. Tu penses à des grosses boites qui centralisent tout, mais il existe des grosses boites qui ont utilisé BitKeeper bien décentralisé bien avant que Git existe. ce n'est pas une question de taille, mais de "design". Tout comme ce n'est pas une question d'open source. ce n'est pas la partie méprisante qui est la plus gênante, mais ne pas voir que c'est orthogonal. Il ne faut surtout pas mélanger sous couvert de simplifier (simplifier ne doit pas tromper), et surtout voir qu'on a merdé dans la simplification (et non ce n'est pas une attaque, tout le monde merde un jour, moi compris et pas qu'un peu), c'est ma plus forte réaction.
Donc maintenant que ce point est clos, repartons sur le sujet :
j'ai pu bosser avec git. Et là j'en ai bien chié.
Je comprend, en ayant chié aussi.
Mais aussi pour une raison que tu as aussi : je connaissais SVN.
Et tu as oublié comme SVN est difficile à apprendre car c'est loin, mais un débutant n'a pas vraiment plus de problème avec Git qu'avec SVN, surtout quand on utilise Git comme SVN. J'ai l'impression que tu confonds "Git fait par des fans qui veulent utiliser Git à fond" et "Git qu'on peut utiliser comme SVN" : si tu veux te la jouer "SVN", tu as Git et tu fais des pull, commit, push le tout sur une seule branche d'un seul repo et c'est réglé (contre des update, commit, soit juste une commande de moins…)
Mais apprendre SVN juste parce qu'on a la flemme d'une commande en plus (qui permet de travailler offline, à l'heure de la mobilité d'entreprise…), ce n'est pas la bonne chose à faire pour qui ne connait ni SVN ni Git.
Heureusement, je me suis un peu calmé depuis, surtout que même si les fanboys git sont ceux qui hurlent le plus fort,
Il y a des intégristes fanboys partout, je n'ai jamais dit que Git était génial, j'ai juste dit qu'il n'y a plus aucun cas où SVN est conseillable. Si tu n'es pas d'accord, je demande un cas d'usage.
J'en ai donné un, le truc le plus basique, et c'est une commande en plus (pour toute personne non geek : un clic en plus) contre un confort en plus (commiter offline, c'est important en 2016), c'est à prendre pour tout le monde ou presque (les gens codant qu'au bureau avec le serveur Git / réseau online avec QoS 99.999%?), du moins j'attends un exemple où Git est plus compliqué à apprendre utiliser pour le même besoin de 2016 (je précise la date pour les moeurs qui contiennent la mobilité).
Je suis conscient que la violence dans le fond se voit moins que la violence dans la forme, rien de nouveau et c'est la vie de pas mal de monde (pour prendre un exemple classique et troller, le grand classique "je ne suis pas homophobe, je veux débattre avec toi, mais bon hein hors de question de t'autoriser à avoir les même droit que les hétéros", il y a du monde qui joue pas mal sur calmer la forme pour faire passer de la violence sur le fond).
Et je suis conscient aussi que je ne changerai pas le monde sur le sujet, les idées les plus violentes passeront toujours quand la forme y est, donc "passons" (oui je le répète, mais en fait ça m'amuse de voir les fonds violents défendus juste parce que la forme y est).
l'interface de Git (je parle des commandes et des options) pourrait être largement améliorée
C'est aussi quand même se bloquer sur la commande "git".
Perso, je ne l'ai jamais utilisée (j'utilise un IDE qui intégre Git, ou une extension au gestionnaire de fichier)
(bon, par contre oui on met du temps à comprendre push / pull / merge / etc, la je te suis et c'est ce qui m'a fait reculer et passé très tardivement de SVN à Git, perso je n'ai pas encore tout compris mais assez pour faire mon taf)
Bref : on n'a pas besoin de connaitre la commande "git" pour utiliser Git.
Tu rajoutes Gerrit, donc ça va, oui. Mais voila, on en revient que posé comme ça que avec Git, le workflow ne marche pas (efficacement).
Gerrit fait la glue dans ton cas, je vois mal "Git pur" (sans le configurer pour gérer le hook qui va bien) sans rien faire pouvoir bloquer un commit, car par défaut il ne bloque pas le commit justement (donc le système mis en place par l'auteur du journal a un petit soucis faute de CI, ce qu'on fait remarquer).
Quand l'auteur détaillera son workflow pour le CI, on en saura plus (ou pas).
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.
Les (grosses) entreprises n'ont pas attendu Git pour faire du décentralisé (non libre aussi), Bitkeeper par exemple était utilisé par des grosses boites proprio de chez proprio.
Il y a plein de libre centralisé (je dirai même la majorité des projets sur GitHub sont en centralisé dans l'idée, SVN pourrait convenir et ça changerai pas grand chose).
Ne pas le savoir, se mélanger les pinceaux la dessus et trouver une excuse "c'est pour simplifier" quand on le fait remarquer que ça n'a rien à voir, mais parler de quand utiliser SVN ou Git, désolé mais c'est bizarre.
Note que j'ai réagi de cette manière quand on s'est foutu de moi dans la réponse à ma réponse pour noyer le poisson (même pas un "excuse-moi" sincère, non juste une "simplification"), et non au premier commentaire.
Faut parfois regarder comment d'autres attaquent (ce n'est pas parce que la forme est plus jolie que le fond n'est pas violent).
Vraiment, il existe d'autres choses que gitlab, ne restez pas coincé dans des idées aussi coincées.
Tant que tu es conscient que tu as besoin des liens, OK pas de soucis.
Sauf que dans l'exemple du journal, ça ne semble pas du tout l'idée de la personne : je parie qu'elle n'a aucun CI.
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.
hum… De ce que je connais de Jenkins (c'est très vague), il permet de lancer des tests après un merge/commit, et donc trop tard (on fait de la correction à postériori, mieux que rien mais pas le mieux, je l'imagine pour des tests trop longs pour le CI, c'est parfois chiant d'attendre 24 heures que le CI accepte un PR). Comment bloques-tu le PR dans le gestionnaire de version tant que les tests ne sont pas fait avec Jenkins?
Avoir un redmine, un jenkins et un reviewboard c'est très classique par exemple.
Personne ne dit le contraire. Mais généralement on se dit aussi que bon c'est à l'arrache et pas optimal, et qu'on pourrait mieux faire un jour.
On ne sous-entends pas que c'est la bonne méthode, juste celle faite méthode "larache" faute de temps (on sait qu'on payera en temps plus tard, mais bon c'est plus tard) et surtout on ne la conseille pas.
Il existe des gens qui vivent hors de github/gitlab
Quand même de moins en moins (surtout en pourcentage).
Plutôt d’accord avec toi sur le fait qu’un outil simple à utiliser a plus de chance d’être adopté (et correctement utilisé).
Moi aussi.
Mais j'avoue ne pas voir le lien avec SVN (SVN n'étant pas simple à part pour les gens le connaissant, avec plein de "workarounds" à faire pour faire des choses assez basiques)
< L'exemple que j'ai donné sur l'entreprise était une simplification, comme indiqué.
Tu n'as rien simplifier : tu as juste raconté n'importe quoi, et tenté d'opposer des choses complétements orthogonales, ce qui démontre que tu ne connais rien à la chose. ce n'est pas une insulte, juste un constat, et perso il y a aussi plein de choses que ne connais pas (à commencer par l'utilisation avancée de Git).
une opération comme un simple svn update peut être extrêmement fastidieuse sous git.
Euh… Ouais, bof, j'ai un GUI perso, ne connait rien aux commandes Git, et survit très bien, sans me prendre la tête.
Note : j'ai essayé un jour "svn update" dans l'avion sur le serveur à la maison, rien à faire impossible de commiter. Du coup, question efficacité, il a fallu attendre, noter les commits dans un coin, copier les fichiers à chaque étape pour avoir les bon messages avec les bons commits, très lourd. Mais bon, c'est efficace pour toi… note que je parle d'une grosse boite utilisant SVN et pas d'open source, ton "exemple".
Malheureusement, je crois que tu es en train (comme d'hab en fait) de considérer ton nombril comme tout à fait représentatif de l'univers et que tu n'as jamais bossé dans une grosse structure centralisée.
Merci du compliment.
Dans l'attaque, tu es ridicule, tellement GitHub (et sa façon de faire pour les projet) est connu.
Je crois que tu es en train de faire l'autruche et attaquer une personne qui te parle d'un truc que tu n'as simplement pas envie de voir.
Tu sais, on peut aussi avoir vu et s'être rendu compte de la résistance au changement qui est le seul frein pour ne pas être plus efficace dans une grosse structure. Mais de plus, git accepte un serveur central, donc bon on voit bien que le problème n'est pas Git, mais les préjugés dessus (avec Git, on peut faire centralisé et décentralisé, mais les gens pensent que c'est mieux d'opposer).
Note que tu n'as pas donné d'exemple où SVN est mieux que Git (à part un pseudo exemple de "complexité" de Git qui se résout en des scripts de 2-3 lignes à fournir, et encore), et c'est un newbee de Git qui le dit.
Et je me permets de mettre ton « svn est mort, vive git » là ou je range les « le pc est mort, vive la tablette », « windows est mort, vive mac », « le disque dur est mort, vive le cloud », «l'email est mort, vive facebook », « le web est mort, vive les appli smartphone », etc…
Non, vraiment, ça n'a rien à voir : SVN est vraiment mort (en train de mourir), les seuls encore à l'utiliser son les masochistes et les gens ayant un historique, que ça te plaise ou pas.
Note que je n'ai jamais dit tous les exemples que tu as cité (bizarre non? tu m'y catalogues sans me connaitre).
Mais en quoi c'est utile pour le gars qui veut un gestionnaire de version ?
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é).
Perso, j'ai seulement quelques tests dans le CI, mais je sais que le problème est moi, et je ne dis pas "mais on parle pas de ça, on parle de gestionnaire de version", non, je sais que les bonnes pratiques ne sont pas chez moi et que c'est à moi de changer, pas à attaquer les gens qui en parle au bon endroit.
(et le mieux serait le bug tracker associé, qui cloture automatiquement la tâche notée dans le message de commit, pour être encore plus efficace, donc bugtracking dans ton gestionnaire de version ou du moins ton système global, si si).
Git est différent de svn et répond à une problématique différente.
il répond à plus de problématiques, qui inclut les cas de SVN.
En simplifiant, 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.
N'importe quoi, mais vraiment n'importe quoi. A commencer par opposer open source et boite (perso, je suis une boite qui fait de l'open source, alors me dire que je suis soit l'un soit l'autre…)
Certes je ne vais pas répondre la, mais c'est juste pour préciser au lecteur qui se perdrait la qu'il ferait mieux de se renseigner ailleurs (plein d'exemples sur le net) que ce commentaire.
Il semble évident que l'architecture de svn te convient… utilise donc svn !
Non. Car il n'y aucun cas aujourd'hui où SVN convient mieux que Git. Aucun. On répète : vraiment aucun. Au pire vous interdisez les PR si vous n'aimez pas les PR comme plein d'autres gens (qui utilisent Git quand même).
SVN meurt, laissez le mourir tranquillement (=avec ceux qui n'aiment pas le changement, ils partirons à la retraite petit à petit si on ne peut pas les déloger autrement).
Et par ailleurs (juste pour me défouler), en ce moment j'utilise perforce. Bon, n'utilisez jamais cet outil. JAMAIS.
Tu es assez masochistes pour aimer SVN, à partir de la tes conseils sont difficilement utiles (enfin, pour les non masochistes).
je voulais quelque chose de simple, efficace. Le mode de fonctionnement SVN correspond à ce que je veux.
1/ installer un truc chez toi n'est pas simple et efficace par rapport à utiliser un service déjà en ligne. Nous sommes en 2016, pas en 1976.
2/ Le mode de fonctionnement SVN ne correspond pas à ce que tu veux : simple oui, efficace non.
J'ai un peu souffert à comprendre comment utiliser les PR de GitHub, mais depuis, je hurle à chaque fois que je bosse sur le SVN pour un client toujours en SVN, car c'est pas du tout efficace d'avoir besoin de toujours être sur le même truc central.
Sérieusement, avoir SVN et "efficace" dans la même phrase, fallait oser. Même seul Git est largement mieux, ne parlons pas si tu es plus que 1 à travailler dessus.
Bref, la première chose que tu dois faire est soit revoir tes contraintes (efficace etc), soit réserver du temps pour ton plaisir, mais il faut choisir, la tu fais tout l'inverse de es contraintes en "fonctionnalités" et "temps".
Parce que j'aime bien avoir le code produit pas ma société sur un serveur que ma société maîtrise.
OK. Mais alors arrête de dire que tu veux y passer 1 journée, prend le temps, sinon c'est juste une bêtise que tu regretteras le jour où ça crashera (et ça crashera).
Si tu as juste une journée, prend GitHub comme tout le monde qui veut pas y passer plus d'une journée.
Faudrait savoir : tu veux te faire plaisir à réinventer SVN n'importe comment, ou tu dois faire tourner ta boite?
Si l'idée est réellement de faire tourner ta boite, tu as un GitHub (ou GitLab) privé, et tes développeurs font des PR dessus comme 99% de la planète (qui n'utilise pas les fonctions avancées de Git), et surtout tu n'essayes pas de réinventer le passé sans rien comprendre avant (surtout sans comprendre pourquoi le passé genre SVN a été viré).
Bref : tu fais exactement l'inverse de ce que tu dis vouloir faire.
C'est une insulte au libre de ne pas être outré de tels écrits de RMS.
Dans le titre initial de mon commentaire, j'ai mis "intégriste". Ce n'est pas pour rien : justement on le vois ici, la personne dit la vérité, on lui dit "tu peux avoir des ennuis" (donc ça veut dire qu'elles savent que l'exception de vérité ne sera pas appliquée; ha non pardon en fait elles ne se sont pas renseignées et réagisse juste parce qu'on touche à dieu), on moinsse (j'avoue ne pas comprendre comment on peut moinsser "inutile" un commentaire qui fournit une source claire et précise… A moins de confondre "inutile" et "contre mon dieu") dès que ça ne va pas dans le sens qu'on veut, sans réfléchir, et ça hurle qu'on ne respecte pas leur dieu.
J'ai lancé un troll (à dessein), et il suffit de lire les commentaires pour voir que le libre est une religion comme une autre, avec les salafistes et les gens pouvant accepter tout et n'importe quoi (lors des primaires US, question à une militante "- Le Coran dit que les femmes sont inférieures, c'est OK? - C'est horrible et inacceptable! - On vous a caché la couverture c'est la Bible… - Ha alors c'est OK", ici on a la même chose RMS dit que la pédophilie peut être acceptée du coup la pédophilie est acceptable pour certains, du moins ça ne leur pose aucun problème du tout de soutenir un tel personnage), tout comme les intégristes prêts à défendre l'indéfendable (et avec des excuses des plus bidons genre la maintenance quand leur position devient intenable, tranquille).
On a une personne indéfendable dès qu'on creuse un peu (ou qu'on le rencontre, simplement), mais tout est excusable pour certains car c'est lui.
a noter que l'autre "figure à 3 lettres" du FLOSS plus copyfree n'est pas mieux en terme de casseroles (armes etc), mais les "copyfree-istes" ne s'amusent pas à le porter en dieu, justement, et il est même oublié. Il y a des gens qui ont besoin d'un dieu pour se sentir mieux, pas d'autres.
Je ne connaissais pas ces positions de RMS ; positions qui ne sont plus tenables.
Tu vois comme moi que les "fans" de RMS ne savaient non plus, mais que quand elles savent elle ne peuvent pas se dire que oups et du coup défendent des concepts assez costauds. C'est fou comme on peut faire passer des idées comme "ça passe" avec un peu de bidouille.
Bref : on a du joli, comme prévu :), le popcorn est sorti.
(vaut mieux en rire sinon on serait bien triste, et bon ça reste compartimenté, la grande majorité des libristes voient en Stallman que du folklore, et la licence MIT, copyfree, est en train d'être la référence en matière de licence libre).
PS :
qu'eut par ex. "Danny" dans notre pays
A ma connaissance, au contraire de ce qu'on a voulu lui faire porter pour le flinguer, il a juste dit qu'il y pensait sans avoir jamais voulu ni fait la chose car assez conscient que bof; c'est surtout les Verts allemands qui n'ont jamais publiquement dit que leur opinions passées sur le sujet étaient une erreur (pour ne pas "casser" le parti, donc bon en gros ils disent bien qu'ils y a du monde qui se tait car c'est pas porteur / "compréhensible" par l'élécteur)
PPS : je ne vous ai exceptionnellement pas donné beaucoup de commentaires pour vous faire plaisir à moinsser, lâchez vous :-D
ha ha ha…
tu arrives vraiment à le voir comme ça? J'avoue ne pas réussir à trouver le cheminement logique qui amène à cette possibilité, j'imagine que le cerveau humain a de bons labyrinthes.
Perso, je vois plutôt RMS dire implicitement "je pense que les OS libres sont moins bien" car il lie une fonctionnalité d'un logiciel à une fonctionnalité qu'il montre de la pire manière qu'il soit comme inexistante dans les OS libres ("- Voila un patch pour les couleurs sous macOS - refusé car pas sous OS libre", c'est juste dire ça)
Ou comment sous couvert de défense du logiciel libre, on l'enfonce, bravo!
En tant qu'utilisateurs de MacOS, vous vous sentez délaissés, trahis?
En tant que libriste, je trouve que refuser un patch sous excuse bidon dogmatique est une insulte à ceux qui disent tout le temps "contribue! Et quand tu as fini, c'est mieux si tu files upstream". Et après on s'étonne que les gens ne veuillent pas "perdre leur temps" à préparer un patch upstream?
Le libre doit avancer malgré ce genre de personnes.
Ça tombe bien, vous pouvez le forker!
Quand il y a des forks de ce type, ça montre qu'il y a un problème dans la gestion de projet upstream. Forker est une arme possible dans le libre, mais ne devrait pas être conseillée : c'est une arme défensive, "au cas où", pas offensive contre une forme de chantage de l'upstream (mais pourquoi des gens doivent se sentir obligés de faire du chantage "X contre Y"?)
Le pari de la FSF, c'est le pari de l'autarcie du logiciel libre, capable, à terme, de se suffire à lui-même.
Pour se suffire à lui-même, on ne compte pas sur la FSF ou RMS, mais sur Linux, Apache, Mozilla, VideoLAN… Et pleins d'autres projets libres à l'opposé complet de cet intégrisme. L'intégrisme, quelque soit sa base, est source de bordel pour cacher une volonté de ne pas avoir envie de vivre avec les autres, et ne fait pas vraiment avancer (au contraire, ça donne une mauvaise réputation au mouvement).
Le pari de la FSF, c'est d'être dans la caricature et d'être sujet de blagues dans le libre : à trop vouloir faire l'autarcie, on fini par être seul dans son monde.
Petite pensée pour XFree86 et leur pari de l'autarcie.
donc je me permets de publier un journal là-dessus en ce mardi.
Après, tu es Linuxien, donc bon ça correspond à l'ambiance voulue de la "communauté" (combien de fois je me suis fais insulter pour vouloir filer des binaires utilisables par les gens? "c'est pas ton rôle, arrête de faire ta pleureuse, les gens prennent la version du repo de la distro").
Sous Windows ou Mac, clic clic clic, et voila.
Tu as choisi ta communauté :).
Note : tu veux faire une AppImage, donc ne pas savoir quoi lancer la n'est pas crédible ;-).
Plus sérieusement : les distros gèrent bien FF dans les repos, donc seuls les geeks utilisent le tar.gz, pas besoin de doc car ce n'est pas le but que d'utiliser de binaire pour tout le monde. Rien de choquant.
Ça veut dire que le développement de Firefox est contraint par le développement d'extensions indépendantes qui s'interfacent avec FF
Tu découvres la dette technique que maintenant?
C'est depuis le début de l'informatique qu'on a des problème de gestion du passé, tiens on a toujours de la gestion 32-bit dans Linux, les mails qui transportent les pièces jointes en base64 (donc consomment 33% de plus que nécessaire), que plein de sites ne sont pas "aux dernières modes" pour supporter les vieux navigateurs etc…
Bref, oui, il faut gérer l'éco-système, et ça met du temps de faire bouger tout le monde, c'est la vie, et c'est normal sauf à vouloir virer 1% par ci par la (les gens n'utilisent pas les mêmes extensions vitales…)
un certain nombre d'extensions est cruciale, alors elles devraient être incluses dans le code principal
Si quelqu'un a développé, c'est que c'est crucial (pour lui). reste à définir "crucial" pour le logiciel central, et ce n'est pas aussi simple que tu veux le croire.
J'ai du mal à voir l'intérêt d'un système d'extensions
Tu peux n'avoir rien à faire d'un éco-système, mais en pratique c'est l'éco-système qui fait que tu es utilisé ou pas. Si tu n'y vois pas d’intérêt, je te conseille de te renseigner sur l'histoire de Mozilla (qui a eu du succès au début avec cette idée des extensions plus que son support des sites webs)
Je pense que vous devriez mettre comme "juste-à-temps (JIT)" pour "cadriciel", bref la version usité entre parenthèse à défaut d'être juste affichée, genre "cadriciel (framework)".
Personnellement j'ai dû chercher la signification de ce mot ("mais de quoi ils parlent?") comme quand je tombe sur "Danse lascive" ou "Ferrovipathes" pour un titre de film (je me demande de quel film tu parles alors que je le connais ces films, sous un autre nom en France/français utilisé).
On peut dire aussi "personnes" pour éviter le "/".
qui ont probablement une vie avec un budget prévisionnel a établir chaque année.
Tu inverses cause et conséquence, le budget se faisant sur ce qu'on reçoit et non l'inverse (ce n'est pas parce que je peux vivre avec 1000 que je vais chercher 1000, rare sont ceux qui adaptent leur budget à une demande de baisser le salaire si le budget a de la marge, et le budget de le niveau de vie du salarié n'est pas le sujet, plutôt une adéquation entre salaire demandé et compétences)
C'est plutôt "il y des personnes, sans doute les plus intéressantes pour toi, qui vont passer leur chemin car l'absence de fourchette de salaire est souvent synonyme de salaire au rabais et ils ont d'autres annonces intéressantes pour elles pour ne pas perdre leur temps à demander la fourchette de salaire sachant que 90% du temps elle sera inadéquate".
ne nous voilons pas la face, le salaire.
Toute personne disant le contraire est faux cul :), sinon ils travailleraient gratos et étonnamment personne ne souhaite travailler gratos ;-). Perso ça me permet de faire le tri dans les gens corrects avec moi (si ils parlent salaire quand je leur demande les critères, ça veut dire qu'ils n'essayent pas de me mentir, sinon j'avoue douter)
Cela fera gagner du temps a tous
Tout à fait, perso un employeur ne donnant pas directement ses contraintes me ferait douter de sa sincérité, donc autant le balancer direct. On ne le répète pas à chaque fois? Pour quelqu'un qui veut un passionné Linux, il ne lit pas trop les commentaires des autres offres sur LinuxFr ;-).
# Mauvaise comparaison
Posté par Zenitram (site web personnel) . En réponse au journal Joomla et les clubs à abonnement payant. Évalué à 7.
Un warez est contre la volonté de l'auteur.
Ton exemple respecte la volonté de l'auteur.
rien de nouveau, ce qui est vendu est le "nom", la facilité, surtout l'affichage au chef qui ne cherchera pas plus (de tête libcrypto fait plus fort avec du domaine publique mais tu peux aussi acheter une licence)
au passage ici tu fais la pub de l'alternative légale, du coup tu enlèveras potentiellement des sous à l'upstream. Voulu?
[^] # Re: Capté
Posté par Zenitram (site web personnel) . En réponse au journal Programmer ça craint. Évalué à 0. Dernière modification le 26 novembre 2016 à 19:58.
Tout à fait, et j'ai oublié de le préciser.
L'attaque était en partie sur le code "pour Internet", et le protocole Internet parfait les français l'ont fait (ATM, ça allait tout déchirer tellement on avait conçu un bon truc et qu'on avait pensé à tout avec des contrats entre tout les acteurs, enfin tout sauf le coût) et personne ne l'a utilisé, car justement 1% de merde pour Internet est parfaitement acceptable (d'autres l'ont compris et on fait cette "merde" d'IP et d'Ethernet, quoi est utilisé de nos jours?), ce n'est pas un parachute (et si c'est important, tu utilises pas Internet mais un autre truc plus cher et tu es prêt à payer pour).
Tout est question de compromis, la recherche du code parfait n'est pas mieux que de faire trop de code pourri (les deux extrêmes sont pourris). C'est disons amusant de voir une non nouveauté d'attaque contre du "code pourri", je dois me faire vieux mais l'histoire se répète sur les critiques "prenant conscience du niveau du bordel" :), n’empêche à la fin ce n'est jamais le code parfait qui gagne (spoiler: c'est le code qui est un compromis entre fonctionnalités et bugs pour un coût donné).
Bref, une fois n'est pas coutume, on est parfaitement en phase et j'avais oublié cette partie dans ma tirade, merci de le rappeler.
# Capté
Posté par Zenitram (site web personnel) . En réponse au journal Programmer ça craint. Évalué à 3.
Tiens, quelqu'un a lu mon code!
C'est un peu facile.
Perso, je le vois autrement : il vaut mieux du code qui marchote en faisant ce qu'on lui demande dans 99% des cas que du code "parfait" qui fait quasi-rien et donc que personne ne veut (ni utiliser ni payer).
Et si tu as peur, pas de soucis pour recevoir ton argent (10x plus que pour le code qui marchote) pour corriger tout ça, sinon bon ça reste de la théorie : ça ne t’intéresse pas vraiment, sorti du bar du coin, un peu comme les anti-nucléaires toujours chez EDF pour leur électricité (anti, mais sans être prêt à dépenser même pas 10% de plus pour leur convictions, faut pas déconner).
Ca me fait penser à Hurd contre Linux, je préfère le Linux buggué utilisable au Hurd "parfait" inutilisable.
Bref, l'attaque est un peu facile, comme toujours c'est une question de compromis (il ne faut pas non plus que ce soit des trous de sécurité béants diffusés à grande échelle et qui permettent de faire tomber Dyn qui lui doit se taper les conséquences, mais "désespérer" tant que ce n'est pas parfait ne changera pas le monde).
Bon après, je n'ai pas été convaincu par l'humour du texte, ça ne doit pas aider. Va falloir beaucoup plus (cohérent, constructif et réaliste, chiffré genre tu es prête à payer combien en plus pour calmer ton inquiétude ou combien gagnerait le peuple dans son ensemble si on forçait par la loi certains critères dont on a aussi chiffré le coût) pour changer les esprits.
Pas compris de quoi tu parles, entreprise ou perso ne change rien au sujet (comme l'open source / libre n'est pas réservé au perso), et tu sembles associer "sans être payé" à quelque chose qui est réducteur (je ne sais pas exactement quoi, mais tout ce que j'imagine est une réduction de la réalité).
(et oui je me sens un peu attaqué gratuitement en tant que développeur, donc je réagis)
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2. Dernière modification le 26 novembre 2016 à 07:57.
euh…
(et pour le pic sur les idées, c'est quand même bizarre je dis souvent que je sais que je ne fais pas tout parfaitement : désolé, je fais la différence entre ce que je fais et ce qui serait le mieux à faire, est-ce difficile à faire cette différence? Ici par exemple je pourrai très bien ne pas être passé à Git et le conseiller quand même car je sais que je ne suis pas sur le "bon chemin". J'ai l'impression qu'il y a une grosse difficulté à accepter qu'une personne puisse faire la différence entre ce qu'elle fait et ce qu'elle devrait faire, et l'impression que pas mal de monde doit défendre absolument sa façon de faire comme la meilleure car il fait comme ci comme ça sans se dire qu'il faudrait changer, l'impression n'est pas que dans ce journal).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
Pour le même usage, ce n'est pas parce qu'un outil permet plus qu'il est plus compliqué qu'un outil plus simple.
C'est un préjugé classique que d'imaginer que puissant veut dire complexe dans tous les cas (préjugé aussi pour les développeurs qui pour un usage simple vont dire "oui c'est plus compliqué que le concurrent mais c'est parce qu'on propose plus de choses", mauvais développeur qui légitime son incompétence en design par une fausse excuse).
Bref : Oui est (très) compliqué pour des choses assez compliquées que SVN ne permet pas. Mais pour des choses "à la SVN" c'est kif kif pour qui n'a jamais touché à un gestionnaire de version (il ne trouvera pas que commiter en local puis pusher est plus compliqué, il trouvera pas mal de pouvoir commiter dans l'avion et pusher en y sortant, et pétera un câble quand on le forcera à utiliser SVN et que sa connexion Internet a sauté et que donc il peut même pas faire 2-3 commit en attendant, bref les gens hurlent aux manques en se basant sur ce qu'ils ont utilisé en premier).
Euh…
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1. Dernière modification le 25 novembre 2016 à 15:27.
Apprécié.
Mais juste je reprécise : ça n'a vraiment rien à voir. Tu penses à des grosses boites qui centralisent tout, mais il existe des grosses boites qui ont utilisé BitKeeper bien décentralisé bien avant que Git existe. ce n'est pas une question de taille, mais de "design". Tout comme ce n'est pas une question d'open source. ce n'est pas la partie méprisante qui est la plus gênante, mais ne pas voir que c'est orthogonal. Il ne faut surtout pas mélanger sous couvert de simplifier (simplifier ne doit pas tromper), et surtout voir qu'on a merdé dans la simplification (et non ce n'est pas une attaque, tout le monde merde un jour, moi compris et pas qu'un peu), c'est ma plus forte réaction.
Donc maintenant que ce point est clos, repartons sur le sujet :
Je comprend, en ayant chié aussi.
Mais aussi pour une raison que tu as aussi : je connaissais SVN.
Et tu as oublié comme SVN est difficile à apprendre car c'est loin, mais un débutant n'a pas vraiment plus de problème avec Git qu'avec SVN, surtout quand on utilise Git comme SVN. J'ai l'impression que tu confonds "Git fait par des fans qui veulent utiliser Git à fond" et "Git qu'on peut utiliser comme SVN" : si tu veux te la jouer "SVN", tu as Git et tu fais des pull, commit, push le tout sur une seule branche d'un seul repo et c'est réglé (contre des update, commit, soit juste une commande de moins…)
Mais apprendre SVN juste parce qu'on a la flemme d'une commande en plus (qui permet de travailler offline, à l'heure de la mobilité d'entreprise…), ce n'est pas la bonne chose à faire pour qui ne connait ni SVN ni Git.
Il y a des intégristes fanboys partout, je n'ai jamais dit que Git était génial, j'ai juste dit qu'il n'y a plus aucun cas où SVN est conseillable. Si tu n'es pas d'accord, je demande un cas d'usage.
J'en ai donné un, le truc le plus basique, et c'est une commande en plus (pour toute personne non geek : un clic en plus) contre un confort en plus (commiter offline, c'est important en 2016), c'est à prendre pour tout le monde ou presque (les gens codant qu'au bureau avec le serveur Git / réseau online avec QoS 99.999%?), du moins j'attends un exemple où Git est plus compliqué à apprendre utiliser pour le même besoin de 2016 (je précise la date pour les moeurs qui contiennent la mobilité).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -2.
Je suis conscient que la violence dans le fond se voit moins que la violence dans la forme, rien de nouveau et c'est la vie de pas mal de monde (pour prendre un exemple classique et troller, le grand classique "je ne suis pas homophobe, je veux débattre avec toi, mais bon hein hors de question de t'autoriser à avoir les même droit que les hétéros", il y a du monde qui joue pas mal sur calmer la forme pour faire passer de la violence sur le fond).
Et je suis conscient aussi que je ne changerai pas le monde sur le sujet, les idées les plus violentes passeront toujours quand la forme y est, donc "passons" (oui je le répète, mais en fait ça m'amuse de voir les fonds violents défendus juste parce que la forme y est).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
C'est aussi quand même se bloquer sur la commande "git".
Perso, je ne l'ai jamais utilisée (j'utilise un IDE qui intégre Git, ou une extension au gestionnaire de fichier)
(bon, par contre oui on met du temps à comprendre push / pull / merge / etc, la je te suis et c'est ce qui m'a fait reculer et passé très tardivement de SVN à Git, perso je n'ai pas encore tout compris mais assez pour faire mon taf)
Bref : on n'a pas besoin de connaitre la commande "git" pour utiliser Git.
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
Tu rajoutes Gerrit, donc ça va, oui. Mais voila, on en revient que posé comme ça que avec Git, le workflow ne marche pas (efficacement).
Gerrit fait la glue dans ton cas, je vois mal "Git pur" (sans le configurer pour gérer le hook qui va bien) sans rien faire pouvoir bloquer un commit, car par défaut il ne bloque pas le commit justement (donc le système mis en place par l'auteur du journal a un petit soucis faute de CI, ce qu'on fait remarquer).
Quand l'auteur détaillera son workflow pour le CI, on en saura plus (ou pas).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -2.
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.
Les (grosses) entreprises n'ont pas attendu Git pour faire du décentralisé (non libre aussi), Bitkeeper par exemple était utilisé par des grosses boites proprio de chez proprio.
Il y a plein de libre centralisé (je dirai même la majorité des projets sur GitHub sont en centralisé dans l'idée, SVN pourrait convenir et ça changerai pas grand chose).
Ne pas le savoir, se mélanger les pinceaux la dessus et trouver une excuse "c'est pour simplifier" quand on le fait remarquer que ça n'a rien à voir, mais parler de quand utiliser SVN ou Git, désolé mais c'est bizarre.
Note que j'ai réagi de cette manière quand on s'est foutu de moi dans la réponse à ma réponse pour noyer le poisson (même pas un "excuse-moi" sincère, non juste une "simplification"), et non au premier commentaire.
Faut parfois regarder comment d'autres attaquent (ce n'est pas parce que la forme est plus jolie que le fond n'est pas violent).
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -1.
Tant que tu es conscient que tu as besoin des liens, OK pas de soucis.
Sauf que dans l'exemple du journal, ça ne semble pas du tout l'idée de la personne : je parie qu'elle n'a aucun CI.
hum… De ce que je connais de Jenkins (c'est très vague), il permet de lancer des tests après un merge/commit, et donc trop tard (on fait de la correction à postériori, mieux que rien mais pas le mieux, je l'imagine pour des tests trop longs pour le CI, c'est parfois chiant d'attendre 24 heures que le CI accepte un PR). Comment bloques-tu le PR dans le gestionnaire de version tant que les tests ne sont pas fait avec Jenkins?
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
Personne ne dit le contraire. Mais généralement on se dit aussi que bon c'est à l'arrache et pas optimal, et qu'on pourrait mieux faire un jour.
On ne sous-entends pas que c'est la bonne méthode, juste celle faite méthode "larache" faute de temps (on sait qu'on payera en temps plus tard, mais bon c'est plus tard) et surtout on ne la conseille pas.
Quand même de moins en moins (surtout en pourcentage).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 1.
Moi aussi.
Mais j'avoue ne pas voir le lien avec SVN (SVN n'étant pas simple à part pour les gens le connaissant, avec plein de "workarounds" à faire pour faire des choses assez basiques)
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -1.
< L'exemple que j'ai donné sur l'entreprise était une simplification, comme indiqué.
Tu n'as rien simplifier : tu as juste raconté n'importe quoi, et tenté d'opposer des choses complétements orthogonales, ce qui démontre que tu ne connais rien à la chose. ce n'est pas une insulte, juste un constat, et perso il y a aussi plein de choses que ne connais pas (à commencer par l'utilisation avancée de Git).
Euh… Ouais, bof, j'ai un GUI perso, ne connait rien aux commandes Git, et survit très bien, sans me prendre la tête.
Note : j'ai essayé un jour "svn update" dans l'avion sur le serveur à la maison, rien à faire impossible de commiter. Du coup, question efficacité, il a fallu attendre, noter les commits dans un coin, copier les fichiers à chaque étape pour avoir les bon messages avec les bons commits, très lourd. Mais bon, c'est efficace pour toi… note que je parle d'une grosse boite utilisant SVN et pas d'open source, ton "exemple".
Merci du compliment.
Dans l'attaque, tu es ridicule, tellement GitHub (et sa façon de faire pour les projet) est connu.
Je crois que tu es en train de faire l'autruche et attaquer une personne qui te parle d'un truc que tu n'as simplement pas envie de voir.
Tu sais, on peut aussi avoir vu et s'être rendu compte de la résistance au changement qui est le seul frein pour ne pas être plus efficace dans une grosse structure. Mais de plus, git accepte un serveur central, donc bon on voit bien que le problème n'est pas Git, mais les préjugés dessus (avec Git, on peut faire centralisé et décentralisé, mais les gens pensent que c'est mieux d'opposer).
Note que tu n'as pas donné d'exemple où SVN est mieux que Git (à part un pseudo exemple de "complexité" de Git qui se résout en des scripts de 2-3 lignes à fournir, et encore), et c'est un newbee de Git qui le dit.
Non, vraiment, ça n'a rien à voir : SVN est vraiment mort (en train de mourir), les seuls encore à l'utiliser son les masochistes et les gens ayant un historique, que ça te plaise ou pas.
Note que je n'ai jamais dit tous les exemples que tu as cité (bizarre non? tu m'y catalogues sans me connaitre).
Passons…
[^] # Re: Oubliez le bling-bling, et revenez à l'essentiel !
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à -1.
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é).
Perso, j'ai seulement quelques tests dans le CI, mais je sais que le problème est moi, et je ne dis pas "mais on parle pas de ça, on parle de gestionnaire de version", non, je sais que les bonnes pratiques ne sont pas chez moi et que c'est à moi de changer, pas à attaquer les gens qui en parle au bon endroit.
(et le mieux serait le bug tracker associé, qui cloture automatiquement la tâche notée dans le message de commit, pour être encore plus efficace, donc bugtracking dans ton gestionnaire de version ou du moins ton système global, si si).
[^] # Re: git != svn
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3. Dernière modification le 25 novembre 2016 à 12:28.
il répond à plus de problématiques, qui inclut les cas de SVN.
N'importe quoi, mais vraiment n'importe quoi. A commencer par opposer open source et boite (perso, je suis une boite qui fait de l'open source, alors me dire que je suis soit l'un soit l'autre…)
Certes je ne vais pas répondre la, mais c'est juste pour préciser au lecteur qui se perdrait la qu'il ferait mieux de se renseigner ailleurs (plein d'exemples sur le net) que ce commentaire.
Non. Car il n'y aucun cas aujourd'hui où SVN convient mieux que Git. Aucun. On répète : vraiment aucun. Au pire vous interdisez les PR si vous n'aimez pas les PR comme plein d'autres gens (qui utilisent Git quand même).
SVN meurt, laissez le mourir tranquillement (=avec ceux qui n'aiment pas le changement, ils partirons à la retraite petit à petit si on ne peut pas les déloger autrement).
Tu es assez masochistes pour aimer SVN, à partir de la tes conseils sont difficilement utiles (enfin, pour les non masochistes).
# conclusion inverse à la demande
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 2. Dernière modification le 25 novembre 2016 à 11:46.
1/ installer un truc chez toi n'est pas simple et efficace par rapport à utiliser un service déjà en ligne. Nous sommes en 2016, pas en 1976.
2/ Le mode de fonctionnement SVN ne correspond pas à ce que tu veux : simple oui, efficace non.
J'ai un peu souffert à comprendre comment utiliser les PR de GitHub, mais depuis, je hurle à chaque fois que je bosse sur le SVN pour un client toujours en SVN, car c'est pas du tout efficace d'avoir besoin de toujours être sur le même truc central.
Sérieusement, avoir SVN et "efficace" dans la même phrase, fallait oser. Même seul Git est largement mieux, ne parlons pas si tu es plus que 1 à travailler dessus.
Bref, la première chose que tu dois faire est soit revoir tes contraintes (efficace etc), soit réserver du temps pour ton plaisir, mais il faut choisir, la tu fais tout l'inverse de es contraintes en "fonctionnalités" et "temps".
OK. Mais alors arrête de dire que tu veux y passer 1 journée, prend le temps, sinon c'est juste une bêtise que tu regretteras le jour où ça crashera (et ça crashera).
Si tu as juste une journée, prend GitHub comme tout le monde qui veut pas y passer plus d'une journée.
[^] # Re: git
Posté par Zenitram (site web personnel) . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 6.
Faudrait savoir : tu veux te faire plaisir à réinventer SVN n'importe comment, ou tu dois faire tourner ta boite?
Si l'idée est réellement de faire tourner ta boite, tu as un GitHub (ou GitLab) privé, et tes développeurs font des PR dessus comme 99% de la planète (qui n'utilise pas les fonctions avancées de Git), et surtout tu n'essayes pas de réinventer le passé sans rien comprendre avant (surtout sans comprendre pourquoi le passé genre SVN a été viré).
Bref : tu fais exactement l'inverse de ce que tu dis vouloir faire.
[^] # Re: Mais ça suffit avec Stallman !
Posté par Zenitram (site web personnel) . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à -3. Dernière modification le 22 novembre 2016 à 22:42.
Dans le titre initial de mon commentaire, j'ai mis "intégriste". Ce n'est pas pour rien : justement on le vois ici, la personne dit la vérité, on lui dit "tu peux avoir des ennuis" (donc ça veut dire qu'elles savent que l'exception de vérité ne sera pas appliquée; ha non pardon en fait elles ne se sont pas renseignées et réagisse juste parce qu'on touche à dieu), on moinsse (j'avoue ne pas comprendre comment on peut moinsser "inutile" un commentaire qui fournit une source claire et précise… A moins de confondre "inutile" et "contre mon dieu") dès que ça ne va pas dans le sens qu'on veut, sans réfléchir, et ça hurle qu'on ne respecte pas leur dieu.
J'ai lancé un troll (à dessein), et il suffit de lire les commentaires pour voir que le libre est une religion comme une autre, avec les salafistes et les gens pouvant accepter tout et n'importe quoi (lors des primaires US, question à une militante "- Le Coran dit que les femmes sont inférieures, c'est OK? - C'est horrible et inacceptable! - On vous a caché la couverture c'est la Bible… - Ha alors c'est OK", ici on a la même chose RMS dit que la pédophilie peut être acceptée du coup la pédophilie est acceptable pour certains, du moins ça ne leur pose aucun problème du tout de soutenir un tel personnage), tout comme les intégristes prêts à défendre l'indéfendable (et avec des excuses des plus bidons genre la maintenance quand leur position devient intenable, tranquille).
On a une personne indéfendable dès qu'on creuse un peu (ou qu'on le rencontre, simplement), mais tout est excusable pour certains car c'est lui.
a noter que l'autre "figure à 3 lettres" du FLOSS plus copyfree n'est pas mieux en terme de casseroles (armes etc), mais les "copyfree-istes" ne s'amusent pas à le porter en dieu, justement, et il est même oublié. Il y a des gens qui ont besoin d'un dieu pour se sentir mieux, pas d'autres.
Tu vois comme moi que les "fans" de RMS ne savaient non plus, mais que quand elles savent elle ne peuvent pas se dire que oups et du coup défendent des concepts assez costauds. C'est fou comme on peut faire passer des idées comme "ça passe" avec un peu de bidouille.
Bref : on a du joli, comme prévu :), le popcorn est sorti.
(vaut mieux en rire sinon on serait bien triste, et bon ça reste compartimenté, la grande majorité des libristes voient en Stallman que du folklore, et la licence MIT, copyfree, est en train d'être la référence en matière de licence libre).
PS :
A ma connaissance, au contraire de ce qu'on a voulu lui faire porter pour le flinguer, il a juste dit qu'il y pensait sans avoir jamais voulu ni fait la chose car assez conscient que bof; c'est surtout les Verts allemands qui n'ont jamais publiquement dit que leur opinions passées sur le sujet étaient une erreur (pour ne pas "casser" le parti, donc bon en gros ils disent bien qu'ils y a du monde qui se tait car c'est pas porteur / "compréhensible" par l'élécteur)
PPS : je ne vous ai exceptionnellement pas donné beaucoup de commentaires pour vous faire plaisir à moinsser, lâchez vous :-D
# Ha les intégristes du libre...
Posté par Zenitram (site web personnel) . En réponse au journal De l'autarcie du projet GNU, ou comment Emacs ne veut pas devenir EmacOs. Évalué à -10.
ha ha ha…
tu arrives vraiment à le voir comme ça? J'avoue ne pas réussir à trouver le cheminement logique qui amène à cette possibilité, j'imagine que le cerveau humain a de bons labyrinthes.
Perso, je vois plutôt RMS dire implicitement "je pense que les OS libres sont moins bien" car il lie une fonctionnalité d'un logiciel à une fonctionnalité qu'il montre de la pire manière qu'il soit comme inexistante dans les OS libres ("- Voila un patch pour les couleurs sous macOS - refusé car pas sous OS libre", c'est juste dire ça)
Ou comment sous couvert de défense du logiciel libre, on l'enfonce, bravo!
En tant que libriste, je trouve que refuser un patch sous excuse bidon dogmatique est une insulte à ceux qui disent tout le temps "contribue! Et quand tu as fini, c'est mieux si tu files upstream". Et après on s'étonne que les gens ne veuillent pas "perdre leur temps" à préparer un patch upstream?
Le libre doit avancer malgré ce genre de personnes.
Quand il y a des forks de ce type, ça montre qu'il y a un problème dans la gestion de projet upstream. Forker est une arme possible dans le libre, mais ne devrait pas être conseillée : c'est une arme défensive, "au cas où", pas offensive contre une forme de chantage de l'upstream (mais pourquoi des gens doivent se sentir obligés de faire du chantage "X contre Y"?)
Pour se suffire à lui-même, on ne compte pas sur la FSF ou RMS, mais sur Linux, Apache, Mozilla, VideoLAN… Et pleins d'autres projets libres à l'opposé complet de cet intégrisme. L'intégrisme, quelque soit sa base, est source de bordel pour cacher une volonté de ne pas avoir envie de vivre avec les autres, et ne fait pas vraiment avancer (au contraire, ça donne une mauvaise réputation au mouvement).
Le pari de la FSF, c'est d'être dans la caricature et d'être sujet de blagues dans le libre : à trop vouloir faire l'autarcie, on fini par être seul dans son monde.
Petite pensée pour XFree86 et leur pari de l'autarcie.
Tu aurais pu attendre vendredi!
Bon troll.
[^] # Re: installation pas *user-friendly*
Posté par Zenitram (site web personnel) . En réponse à la dépêche Firefox 50 Cent. Évalué à -6. Dernière modification le 18 novembre 2016 à 14:04.
Après, tu es Linuxien, donc bon ça correspond à l'ambiance voulue de la "communauté" (combien de fois je me suis fais insulter pour vouloir filer des binaires utilisables par les gens? "c'est pas ton rôle, arrête de faire ta pleureuse, les gens prennent la version du repo de la distro").
Sous Windows ou Mac, clic clic clic, et voila.
Tu as choisi ta communauté :).
Note : tu veux faire une AppImage, donc ne pas savoir quoi lancer la n'est pas crédible ;-).
Plus sérieusement : les distros gèrent bien FF dans les repos, donc seuls les geeks utilisent le tar.gz, pas besoin de doc car ce n'est pas le but que d'utiliser de binaire pour tout le monde. Rien de choquant.
[^] # Re: Flexibilité du développement
Posté par Zenitram (site web personnel) . En réponse à la dépêche Firefox 50 Cent. Évalué à 10.
Tu découvres la dette technique que maintenant?
C'est depuis le début de l'informatique qu'on a des problème de gestion du passé, tiens on a toujours de la gestion 32-bit dans Linux, les mails qui transportent les pièces jointes en base64 (donc consomment 33% de plus que nécessaire), que plein de sites ne sont pas "aux dernières modes" pour supporter les vieux navigateurs etc…
Bref, oui, il faut gérer l'éco-système, et ça met du temps de faire bouger tout le monde, c'est la vie, et c'est normal sauf à vouloir virer 1% par ci par la (les gens n'utilisent pas les mêmes extensions vitales…)
Si quelqu'un a développé, c'est que c'est crucial (pour lui). reste à définir "crucial" pour le logiciel central, et ce n'est pas aussi simple que tu veux le croire.
Tu peux n'avoir rien à faire d'un éco-système, mais en pratique c'est l'éco-système qui fait que tu es utilisé ou pas. Si tu n'y vois pas d’intérêt, je te conseille de te renseigner sur l'histoire de Mozilla (qui a eu du succès au début avec cette idée des extensions plus que son support des sites webs)
# [HS] Traduction à la québecoise
Posté par Zenitram (site web personnel) . En réponse à la dépêche Pendant ce temps, dans l’écosystème Ruby. Évalué à 5. Dernière modification le 17 novembre 2016 à 08:17.
Je pense que vous devriez mettre comme "juste-à-temps (JIT)" pour "cadriciel", bref la version usité entre parenthèse à défaut d'être juste affichée, genre "cadriciel (framework)".
Personnellement j'ai dû chercher la signification de ce mot ("mais de quoi ils parlent?") comme quand je tombe sur "Danse lascive" ou "Ferrovipathes" pour un titre de film (je me demande de quel film tu parles alors que je le connais ces films, sous un autre nom en France/français utilisé).
[^] # Re: et le salaire ?
Posté par Zenitram (site web personnel) . En réponse au message Administrateur Système Linux Junior H/F. Évalué à 1. Dernière modification le 16 novembre 2016 à 12:39.
On peut dire aussi "personnes" pour éviter le "/".
Tu inverses cause et conséquence, le budget se faisant sur ce qu'on reçoit et non l'inverse (ce n'est pas parce que je peux vivre avec 1000 que je vais chercher 1000, rare sont ceux qui adaptent leur budget à une demande de baisser le salaire si le budget a de la marge, et le budget de le niveau de vie du salarié n'est pas le sujet, plutôt une adéquation entre salaire demandé et compétences)
C'est plutôt "il y des personnes, sans doute les plus intéressantes pour toi, qui vont passer leur chemin car l'absence de fourchette de salaire est souvent synonyme de salaire au rabais et ils ont d'autres annonces intéressantes pour elles pour ne pas perdre leur temps à demander la fourchette de salaire sachant que 90% du temps elle sera inadéquate".
Toute personne disant le contraire est faux cul :), sinon ils travailleraient gratos et étonnamment personne ne souhaite travailler gratos ;-). Perso ça me permet de faire le tri dans les gens corrects avec moi (si ils parlent salaire quand je leur demande les critères, ça veut dire qu'ils n'essayent pas de me mentir, sinon j'avoue douter)
Tout à fait, perso un employeur ne donnant pas directement ses contraintes me ferait douter de sa sincérité, donc autant le balancer direct. On ne le répète pas à chaque fois? Pour quelqu'un qui veut un passionné Linux, il ne lit pas trop les commentaires des autres offres sur LinuxFr ;-).
[^] # Re: Question HS
Posté par Zenitram (site web personnel) . En réponse au message Administrateur Système Linux Junior H/F. Évalué à 1.
Il existe le sexe indéterminé ("unbestimmt") par exemple en Allemagne, je me demande si "H/F" ne serait pas discriminant dans ce pays.
Toujours est-il que vouloir cataloguer les gens en homme ou femme est réducteur (vue réduite sur ce qui existe).