La rumeur courait depuis quelques jours, mais là ça vient d'être annoncé officiellement.
La principale forge de code libre/open-source/diffusé/pas libre/etc. vient de passer dans les mains du gros monsieur qui possède déjà LinkedIn et flight simulator (entre autres (ok je trolle, patapé)).
Il y a quelques années, Microsoft était la boîte honnie des libristes et les logiciels libres avaient leur code hébergé sur sourceforge. Aujourd'hui, Microsoft clame qu'il aime le logiciel libre, contribue même à beaucoup de projets, et sourceforge bien qu'existant encore, n'est plus grand-chose, et les logiciels libres ont migré sur d'autres plates-formes, mais c'est Github qui a raflé le gros morceau, en facilitant la vie pour les codeurs et surtout en se rendant indispensable. Tu vas là parce qu'il y a le plus de monde, et ça s'auto alimente ainsi, au détriment des autres type gitlab ou framagit.
En même temps, le monde du logiciel libre à aussi changé et est devenu moins "politisé" j'ai l'impression. Est-ce que ce rachat va inciter les libristes à migrer vers une autre forge? Et d'ailleurs pourquoi le feraient-ils?
Gitlab veut quand-même essayer d'attirer ceux que ça pourrait rebuter en la jouant bon joueur tout de même.
C'est vrai que ça m'intrigue beaucoup cette histoire, Github est devenu au fil du temps un réseau social pour moi et j'y passe beaucoup de temps. Je ne pense pas migrer tout mon code sur une autre forge dans un avenir proche mais je vais suivre les évolutions avec grand intérêt…
# Je suis passé à Gitlab
Posté par Morovaille . Évalué à 10.
il y a un an maintenant, et je ne le regrette pas. L'interface est plus agréable, tout ce qui est CI est plus ergonomique, etc.
Ça vaut toujours le coup de tenter l'expérience ;)
Ce commentaire est libre de droit, vous pouvez le réutiliser comme bon vous semble.
[^] # Re: Je suis passé à Gitlab
Posté par gnumdk (site web personnel) . Évalué à 10. Dernière modification le 04 juin 2018 à 07:53.
Idem, j'ai migré mes projets vers gitlab.gnome.org et c'est vraiment un meilleur produit.
Je ne pense pas que la communauté soit moins politisée, la migration est déjà en cours et cette nouvelle va accélérer les choses.
Il n'y objectivement aucune raison valable de rester sur GitHub, l'argument du "tu auras moins de contributeurs" est une légende, la majorité des gens qui ont un compte GitHub ne font que «forker» des répos (pour faire genre) et ajouter des étoiles à des projets.
Les quelques contributeurs que j'ai sur mes projets m'ont suivi sur GitLab.
[^] # Re: Je suis passé à Gitlab
Posté par Bisaloo . Évalué à 5.
Pourquoi plutôt l'instance de gnome (gitlab.gnome.org) plutôt que l'instance de gitlab.com ?
Parce que tes applications sont plutôt liées à l'écosystème gnome ou alors il y a des différences importantes entre les deux instances ?
[^] # Re: Je suis passé à Gitlab
Posté par ff9097 . Évalué à 2.
Voici les différences : https://about.gitlab.com/pricing/#self-hosted
[^] # Re: Je suis passé à Gitlab
Posté par gnumdk (site web personnel) . Évalué à 8.
Parce que mes applications sont des applications pour GNOME ;)
[^] # Re: Je suis passé à Gitlab
Posté par voxdemonix . Évalué à 2.
Vu que gitlab est auto hebergeable, les inscriptions/connexions se font-elles en fédération ?
[^] # Re: Je suis passé à Gitlab
Posté par Misc (site web personnel) . Évalué à 6.
Non.
Par contre, c'est largement personnalisable, et ça s'appuie sur une gem ruby du nom de omniauth qui supporte quand même un peu tout sous le soleil. Tu peux mettre de l'openid, du saml, etc, etc.
[^] # Re: Je suis passé à Gitlab
Posté par wilk . Évalué à 8.
Xavier me souffle
[^] # Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par claudex . Évalué à 4.
https://jobs.lever.co/gitlab/a9ec2996-b7b6-4d87-aed0-1fc2ce3f8faa
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
La citation complète :
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par voxdemonix . Évalué à -2. Dernière modification le 07 juin 2018 à 17:08.
Merci pour l'infos, surtout pour ceux qui comme moi sont en train d'effectuer leur migration et de supprimer leurs repos github :D
Gitlab compte rester chez crapsoft ou compte revenir à son propre hébergement ? (edit : ah, réponse juste ci-haut)
Savez-vous si des projets libre sont déjà en train de réagir à cette horreur, genre migrer vers de la concurrence ou se bouger le cul pour enfin créer un truc décentralisé ET fédéré, ou si pour le moment tout le monde accuse le coups ?
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par Psychofox (Mastodon) . Évalué à 2.
Ben git c'est décentralisé dans le sens où tu peux avoir de multiple remotes. Après t'as des trucs comme gittorrent ou git-ssb qui poussent le truc un peu plus loin.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par RyDroid . Évalué à 4.
https://framasphere.org/posts/5141321#5d355e304cce01364ea62a0000053625
https://social.logilab.org/@nspanti/100163499683169688
https://www.goffi.org/b/khii3yEKWDhmNYSDt5GGrY/vers-forge-decentralisee-basee-xmpp
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Ou alors on arrête d'utiliser le flow "merge requests" de Github. Par exemple, en utilisant le flow de Gerrit, qui marche vraiment pas mal et ne nécessite pas la notion de "forks" sur une même instance de l'hébergement.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par louiz’ (site web personnel) . Évalué à 3.
Et c’est quoi ce flow gerrit ?
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par Psychofox (Mastodon) . Évalué à 6.
Gerrit est un outil avec interface web de visualisation et validation de commits.
C'est plus facile par l'exemple, voici le workflow avec n développeurs sur un dépot git simple master :
Voici ce qui se passe sur github:
Ici John a créé le repo sur github et pousse ses modifs direcement dessus.
Carlos aimerait faire de même mais pour pouvoir pousser ses modifs il faudrait que John lui donne les droits dans son dépot. C'est la méthode crasseuse.
La méthode recommandée par github est celle faite par Sam, faire un clone sur un autre repo github et ensuite des pull request pour que John les incorpore à son repo. C'est plus propre, mais admettons le c'est complètement alambiqué et n'imorte quoi de devoir créer autant de clones sur github que de developpeurs qui vont en plus après les recloner sur autant de machines qu'ils utilisent.
Avec un outil comme gerrit on peut avoir un workflow un peu plus simple tout en ayant une vérification du code proposé:
Toujours n developpers mais pas plus de 2 repos centralisés, un pour les changements en attente et l'autre pour le code qui a été validé via gerrit.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par windu.2b . Évalué à 2.
Si je comprends bien, avec Gerrit, on a autant de branches poussées, via
fetch, par des développeurs externes, qu'on aurait de demandes depull-requestavec Github ?[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par Sufflope (site web personnel) . Évalué à 6.
C'est assez malhonnête de représenter github (le "mauvais") en surchargeant le schéma de toutes les commandes locales en allant jusqu'aux
git add, et pour Gerrit (le "bon") un simplefetch(tavu comment c'est simple !!) qui par magie résume tout.[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par Psychofox (Mastodon) . Évalué à 3.
J'ai choisi ce que j'ai pu trouver en 2 minutes via une recherche d'image hein. Rien à voir avec de la malhonnêteté.
L'idée c'est que la méthode des clones multiple sur github revient à créer quasi autant de dépots sur github que de developpeurs alors qu'une méthode utilisant gerrit n'aura besoin que de 2 remotes (note qu'on peut utiliser gerrit avec github). On a déjà les branches dans git, pourquoi vouloir en plus que chacun ait sa copie locale et sa copie remote et doive encore faire des request.
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par CrEv (site web personnel) . Évalué à 2.
Quelle est la différencre entre une pull request entre une branche d'un fork et le dépôt d'authorité, et entre deux branches du dépôt d'authorité ?
Github se charge d'abstraire les remotes et propose toutes les pull request directement accessible par la remote (c'est juste un namespace de branches différent).
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par Psychofox (Mastodon) . Évalué à 1. Dernière modification le 13 juin 2018 à 09:35.
Ah mais je ne dis pas que dans les faits ça marche très bien. Je dis juste que la solution est un peu alambiquée sur le papier (et qu'ils doivent être content que la dedup existe).
[^] # Re: Pour tous ceux qui sont passés à GitLab (le site gitlab.com) :
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Personnellement, le gros projet auquel je contribue depuis longtemps était déjà auto hébergé, et le reste n'est pas spécialement critique et donc hébergé soit sur github, soit sur gitlab, soit chez moi sur mon serveur en fonction de l'humeur du jour. Et je ne prévois pas spécialement de tout déplacer (j'ai autre chose à faire et ça n'a pas d'intérêt dans l'immédiat).
# Pour ceux qui veulent aider à construire une forge décentralisée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 10.
Ça dépend pour qui, nous avons jusqu'ici refusé d'utiliser Github (ou Facebook, ou Twitter) pour notre projet et association entre autre pour des raisons politiques. On ne crache pas pour autant sur ceux qui le font, et on s'est tout de même posé la question plus d'une fois notamment en assemblée générale. J'ai d'ailleurs un compte pour les contributions à d'autres projets.
Pour info j'ai commencé à intégrer des outils de forge décentralisés dans Salut à Toi, en particulier tickets et merge requests (cf. mon billet sur le sujet), le tout basé sur XMPP donc. C'est aussi agnostique de l'outil : c'est utilisé avec Mercurial pour SàT, mais l'intégration de git est prévu.
S'il y a des gens qui veulent participer à l'élaboration d'une forge décentralisée, qui est déjà fonctionnelle et qui est faite dans un langage populaire (Python), n'hésitez pas à me contacter et ou à venir sur notre salon XMPP (sat@chat.jabberfr.org), de l'aide ne serait pas de trop.
[^] # Re: Pour ceux qui veulent aider à construire une forge décentralisée
Posté par ZeroHeure . Évalué à 10.
C'est dommage que Fossil ne soit pas Git ! Fossil est à la fois un gestionnaire de version et une forge décentralisée. À ma connaissance c'est le seul outil de ce genre.
Ça vaut le coup de s'en inspirer pour ton projet d'ailleurs, c'est plutôt bien foutu.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: Pour ceux qui veulent aider à construire une forge décentralisée
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ben là justement c'est agnostique de l'outil, on l'utilise avec Mercurial mais on pourrait utiliser n'importe quoi, et pas forcement que pour du code d'ailleurs. Après par rapport à Fossil, c'est un peu plus compliqué parce qu'il faut un serveur XMPP, mais sinon pratiquement tout est intégré, y compris le serveur web.
Pour s'inspirer au niveau de l'interface j'aimerais bien mais pour le moment je n'en ai pas le temps, donc l'interface est faite pour répondre à nos principaux besoins, et va s'améliorer petit à petit. C'est un des points où de l'aide serait bienvenue d'ailleurs, surtout qu'on a un système de thème facile à utiliser et qui permet de tout changer.
[^] # Re: Pour ceux qui veulent aider à construire une forge décentralisée
Posté par lockidor . Évalué à 2.
Juste pour info, il y a déjà des des discussions dans ce sens pour Gitlab.
[^] # Re: Pour ceux qui veulent aider à construire une forge décentralisée
Posté par ManonM . Évalué à 4.
Bonjour
Si tu veux regarder, on a ouvert notre plateforme Tuleap.net (basée sur l'outil libre et français Tuleap) à tous les projets publics et open source. Sur Tuleap.net, tu peux maintenant:
- Planifier ton projet avec un espace type Scrum ou tableau Kanban
- Héberger et gérer ton code avec git ou Subversion et discuter en ligne avec les pull requests
- Suivre tous type d'artefacts : taches, stories, incident, etc, avec plusieurs trackers par projet si tu veux
- Gérer des documents
- Gérer tes campagnes de tests
- Livrer ton boulot!
Plus d'infos sur Tuleap: https://www.tuleap.org/
[^] # Re: Pour ceux qui veulent aider à construire une forge décentralisée
Posté par RyDroid . Évalué à 2.
C'est cool, mais en quoi cela a t'il un rapport avec le message de Goffi ? Il veut faire une forge décentralisée et il utilise mercurial, ce qui ne semble pas vraiment compatible avec Tuleap à l'heure actuelle. J'ai rien contre Tuleap et Enalean (l'entreprise lucrative derrière), mais là ça fait "on avait voulu insérer notre publicité", ce qui (il me semble) n'est pas super bon pour votre image.
# Pourquoi le feraient-ils ?
Posté par Jérôme Flesch (site web personnel) . Évalué à 10.
Pourquoi migrer ? Je dirais pour ne pas attendre que Microsoft trouve un moyen de planter un couteau dans le dos à ses utilisateurs.
Le premier problème que je vois venir, c'est ce qui est arrivé à LinkedIn. Avant son rachat, LinkedIn était à-peu-près utilisable. Depuis, mon ressenti, c'est que l'interface est devenue nettement plus chargée. Il y a notamment nettement plus de publicités (encart en haut à droite, post d'actualité "promu", etc). Depuis le rachat, LinkedIn me propose aussi de suivre un seul et unique "influenceur": Bill Gates. Pour un anti-Microsoft primaire comme moi, je trouve ça très ironique.
Une fois racheté, il faut que ce soit le plus rentable possible, et donc le plus pourri possible. Je suis donc certain qu'ils trouveront d'autres moyens de pourrir la vie de leurs utilisateurs.
Donc une fois le rachat confirmé, le plan pour moi:
- Tout les dépôts OpenPaperwork seront migrés sur gitlab.gnome.org (changement prévu de longue dates de toute façon).
- Tout mes dépôts personnels seront migrés soit sur framagit.org soit sur un serveur perso.
[^] # A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par totof2000 . Évalué à 6.
En effet, github, c'est aussi un service payant aux entreprises, et je pense que c'est surtout ça qui intéresse Microsoft.Et je suis d'avis qu'ils n'on rien à faire que les projets libres migrent ailleurs. Maintenant, ce qui est bien c'est qu'il y a des alternatives viables qui permettent de migrer si on n'aime pas Microsoft.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Étrange comme stratégie de poser des milliards sur la table (parce que la valorisation de github est certainement beaucoup basée sur le volume des logiciels libres qui le peuplent) pour n'en avoir rien à carrer que ces logiciels se tirent ailleurs au risque de créer un "nouveau" github.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Les logiciels libres, ce n'est pas important quand on acquiert un Github, parce que même si ils vont ailleurs, leur code source restera dispo quelque part.
Par contre, une chose que personne n'a accès publiquement, ce sont les milliers de dépôt privés de sociétés petites ou grosses, dont certaines probablement des concurrents directs. Microsoft va avoir accès à des milliers de "secrets industriels".
C'est ça qui vaut des milliards.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par totof2000 . Évalué à 6.
C'est aussi la réflexion que je me suis faite dans le train ce matin, après avoir posté ce commentaire. Et ce rachat pose la question de l'externalisation de ses données.
Avec le rachat de github, des sociétés potentiellement en concurrence avec Microsoft peuvent se faire du souci. Mais d'un autre côté, il faut se poser la question pour toutes les données qu'on externalise. Pour ma part je trouve aberrant que des boites externalisent leur messagerie à des tiers. Je suis peut-être le seul à penser ainsi, mais supposons qu'une grosse banque a externalisé sa messagerie ches Microsoft, et que demain, Microsoft décide de revendre son service d'hébergement à une banque concurrente, ou qu'une banque concurrente vienne à prendre des participations dans le service de messagerie de Microsoft ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Prosper . Évalué à 1.
D'accord , et ils en feraient quoi ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Jérôme Flesch (site web personnel) . Évalué à 10.
Les gens disaient la même chose de Facebook: "D'accord Facebook collecte mes préférences, informations personnelles s'en sert et les revend, et après ?". Après, Cambridge Analytica s'est servi des informations pour essayer (réussir?) de manipuler les élections américaines.
Est-ce qu'il faut vraiment attendre le prochain scandale ?
L'information c'est le pouvoir, et le pouvoir corrompt. Donnez trop d'information à une entreprise, c'est l'abus de pouvoir assuré.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Misc (site web personnel) . Évalué à 8.
La différence, c'est que la revente de données à CA a été en partie un détournement de CA (données mal protégés), et en partie du au fait que c'est le business model de facebook (ciblage publicitaire, qui a du coup été utilisé pour des campagnes politiques).
Dans le cas de GH/Microsoft, si Microsoft va lire le code source d'un concurrent, c'est une violation de contrat assez lourde.
Et autant dans le cas de FAcebook/CA, un recours serait assez long et couteux pour un particulier, autant une boite qui se fait voler le code source par son hebergeur qui a dit "je le ferait pas", c'est une autre paire de manche, parce que tu as 2 entités avec de l'argent des 2 cotés, et un contrat clair qui dit "on va pas faire ça".
Et bon, quand on voit l'affaire de Uber vs Waymo, le coeur de l'affaire est l'accusation de vol en interne par Anthony Levandowski. On agite souvent l'épouvantail du presta qui vole les infos, mais c'est pas ce qui arrive du tout en pratique. Bien sur, il y a le risque d'un employé malfaisant, mais c’était déjà le cas avec Github. y a le risque du gouvernement qui fasse pression, mais pareil, c'était le cas de Github avant.
Y a sans doute plein de raisons de pas aimer le rachat, mais le risque que Microsoft perde des millions pour lire le code source d'une PME n'en fait sans doute pas partie.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par totof2000 . Évalué à 10.
Certes, mais ce ne sont que des mots : en pratique :
- qui pourra l'en empêcher ?
- comment pourra-t-on le détecter ?
Encore une fois, ce ne sont que des mots. De plus le 'vol' de code n'est pas le seul riqsque : tn code peut révéler des infos sur la stratégie de ta boite, et sans voler de code, un concurrent comme Microsoft saura ou mettre les moyens en interne pour te passer devant.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à -2.
Ben comme d'hab : un employé fuite l'info avec des preuves. Aussi simple que cela.
Il est très très clair qu'ils ne feront jamais cela.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Kerro . Évalué à 1.
Sur les centaines de milliers d'entreprises sur terre qui font des choses illégales, tu en entends beaucoup parler ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à 1.
Vois pas le rapport. On parle d'un cas très précis ici.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par louiz’ (site web personnel) . Évalué à 2.
Le rapport c’est que s’ils font un truc illégal, comment tu fais pour estimer que la chance qu’on le sache est de 100% ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à 2.
Il faut que ce soit 100% ?
Si tu étais en charge d'un truc qui fait des milliards comme Azure et que tu n'avais aucun scrupules (ils en ont certainement mais vu votre approche délirante on va dire qu'ils n'en ont aucun pour vous faire plaisir) tu refuserais de prendre un risque posant un grand danger à ton groupe uniquement si tu es à 100% sur que ca foire ?
Perso je te dirais que vu les conséquences, même un risque minime est évité.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Zenitram (site web personnel) . Évalué à 3.
Si ils se font prendre à regarder les dépôts privés, c'est leur arrêt de mort (en tant qu'entreprise, sans doute aussi des procès pour les personnes, à la Volkswagen). Je doute que quelqu'un votera pour ça au conseil d’administration.
Je doute que c'est avec ça en tête qui posent les milliards sur la table, mais plutôt la base d'utilisateurs.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Jérôme Flesch (site web personnel) . Évalué à 9.
Ah c'est sûr. Facebook démontre d'ailleurs très bien l'importance à donner à la confidentialité des données utilisateurs. Le dernier scandale a bien l'air de les avoir ruinés et d'avoir fait perdre toute valeur à l'entreprise /s (graphique à regarder sur 5 ans pour bien se faire une idée des non-dégâts).
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à 5.
Sauf que ton exemple n'a absolument rien à voir. Dans le cas de FB il est plus qu'évident que les infos des gens sont le mode de paiement pour le service. Ces boites sur github qui paient ont des termes de service qui sont très diffèrents et qui bien évidemment n'incluent pas de partager ces données.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par 태 (site web personnel) . Évalué à 10.
Microsoft l'a déjà fait : https://en.wikipedia.org/wiki/Stac_Electronics#Microsoft_lawsuit et n'en est pas mort (ils ont prétendu vouloir licencier du code de Stac Inc, dans la procédure ils ont eu accès au code, ont rompu les pourparlers et simplement plagié le code… Ils ont été condamnés)
(via https://jacquesmattheij.com/what-is-wrong-with-microsoft-buying-github)
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à 5.
LOL, du grand n'importe quoi.
Il n'y aurait absolument rien de pire pour Microsoft qu'avoir un article dans le New-York Times disant qu'ils piochent dans les données confidentielles de leurs client. Cela tuerait Azure.
Ils ne vont certainement jamais faire cela, ce serait se tirer une balle dans la tête.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par voxdemonix . Évalué à 10.
Plus que d'insérer un keylogger dans windows 10 ?
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à 4.
Il n'y a pas de keylogger dans Windows 10, et je te mets au defi de prouver qu'il y en a un (dans le sens spyware du mot). Ils ont un système, qu'ils ont décrit publiquement, qui sert pour diverses tâches (améliorer la reconnaissance d'écriture, …) et que tout un chacun peut stopper.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Kwiknclean . Évalué à -2.
Wé c'est ce qu'il s'appelle collecter de la méta-data (ça aussi ça va se monnayer très cher dans le futur, ils le savent bien).
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pasBill pasGates . Évalué à -3.
Tu sais, tes paranoias aigues sans la moindre once de preuve, on va dire qu'on s'en fiche éperdument…
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par Kwiknclean . Évalué à 3.
Vue que tu n'en as rien à faire et que tu sembles parler au nom des autres depuis chez toi je vais me permettre d'en rajouter une couche.
Habituellement une société digne de ce nom et respectueuse de ses clients, t'avertis très clairement qu'elle souhaite recueillir ce genre de données avec des popup et messages explicites à l'installation en te proposant clairement de les désactiver. Ce qui si je ne m'abuse n'était absolument pas le cas sur les premières release de Windows 10.
Transparence et communication, sans doute les bonnes vieilles habitudes qui perdurent, voilà qui met en confiance. Et ce peut importe le type de données.
Il a encore fallu que la communauté monte au créneau en allant voir ce qui se passait sous le tapis, pour qu'ensuite ils viennent fournir des explications.
Encore des méthodes parfaitement inadmissible …
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 2.
Tu l'as lu le contrat utilisateur qui est affiché au premier démarrage avant que tu puisses faire quoi que ce soit? Parce que c'est à peu près certain que tout ça était écrit clairement dedans. Et me répond pas "oui mais le texte est trop long": justement, c'est le premier truc qui doit te mettre la puce à l'oreille, ils ont un tas de choses à te faire accepter.
Alors si tu l'as pas lu, vient pas râler qu'on t'as pas prévenu et que c'était fait dans ton dos.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par voxdemonix . Évalué à 4.
Outre des juristes, une seule personne au monde a-t-elle déjà lu ce contrat? (même aux cours on ne l'a pas lu et pourtant on touchait que du windows)
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par xcomcmdr . Évalué à 8.
Oui alors, quand on a un système qui est keyloggable à mort, et ce très facilement (Xorg), on la ramène pas, hein !
Surtout que du côté de Windows, c'est réglé depuis Vista. Soit depuis 2006. La honte.
(et ceux qui moinssent : vous vous en fichez de la sécurité).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par voxdemonix . Évalué à -1. Dernière modification le 08 juin 2018 à 15:26.
D'un côté une faille involontaire, d'un autre des mécanismes mis en place en profitant de la méconnaissance des gens.
D'un côté une erreur de logique de programmation, de l'autre de l'escroquerie pure et dure.
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par xcomcmdr . Évalué à 4. Dernière modification le 08 juin 2018 à 17:27.
Non, une erreur d'architecture fondamentale.
De l'autre, des mensonges de voxdemonix. La charge de la preuve, tout ça : il s'en fout !
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: A mon avis ce ne sont pas les projets libres qui les intéressent.
Posté par tmaguelone . Évalué à 1.
Cool je ne sois pas le seul à m'inquiéter :-)
[^] # Re: Pourquoi le feraient-ils ?
Posté par Victor STINNER (site web personnel) . Évalué à 7.
Je pense que l'IA LinkedIn est imparable et que tu rêves intimement d'être influencé par Bill Gates.
Je suis tombé sur https://twitter.com/movingtogitlab hier : GitLab fait face à une montée en charge depuis les premières rumeurs de rachat. Il risque d'y avoir qq. soucis de perf ces prochains temps ;-)
https://www.dropbox.com/s/uzg9vc5oljr8lin/Screenshot%202018-06-03%2015.52.52.png?dl=0
[^] # Re: Pourquoi le feraient-ils ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
Il ne faut pas aller s'héberger chez Gitlab, mais installer Gitlab chez soi ! (en tout cas quand on est une entreprise).
Qui vous dit que Gitlab ne va pas se faire racheter par un Gafa dans quelques mois, en riposte à ce rachat Github ?
[^] # Re: Pourquoi le feraient-ils ?
Posté par CrEv (site web personnel) . Évalué à 1.
Genre Google qui a déjà bien investi dedans ?
Pourquoi ?
En tant qu'entreprise le boulot peut être de créer des logiciels, pas forcément de maintenir des outils, des serveurs, etc.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Pourquoi ? pour des enjeux stratégiques. Si tu externalises tout, tu affaiblis ta capacité de résiliance et donc de survie. De mon point de vue, pour une boite qui fait du logiciel, des outils comme une forge logiciels, un système d'intégration continue et j'en passe, sont vitaux.
Et c'est pas comme si il fallait 3 semaines pour installer et configurer un gitlab. En une demi-journée c'est plié (ou en un apt-get install "pour voir").
Maintenant chacun met le curseur du compromis sécurité/confidentialité/coût de maintenance où il le sent.
[^] # Re: Pourquoi le feraient-ils ?
Posté par CrEv (site web personnel) . Évalué à 10.
haha
C'est sérieux ? (nan mais je me demande vraiment)
si c'est si critique, c'est pas une demi journée, et ça va demander du taff continu, du taff sur les backups, du taff de monitoring, du taff de maintenance, du taff pour tester les upgrades avant de les déployer, du taff pour fixer les probs le jour où ça se passe mal, du taff pour tester et appliquer les upgrades de distro, etc.
Sinon c'est juste du bricolage.
[^] # Re: Pourquoi le feraient-ils ?
Posté par oau . Évalué à 5.
Franchement gitlab c'est top. apt-get install et c'est ok. En 4ans j'ai eu un unique problème de mise à jour qui a été résolu rapidement.
C'est branché à notre ldap pour les comptes. C'est monitoré avec xymon avec les metrics de base. Vraiment je recommande. C'est propre. Bien plus que zimbra qui est la grosse verrue de mon infra.
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 10.
Perso, je n'ai jamais eu de crash disque. Je déconseille de passer du temps à faire des backups.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par oau . Évalué à 1.
oula. Ca n'arrive pas. Sauf quand ça arrive. Moi je fais des backups plutôt 3 fois qu'une. Ceph répliqué 3 fois. Vm répliquée avec rbd mirroring sur un second cluster ceph et un backup borg toute les heures. Sur site ET hors site. Comme pour toute mes vm en fait.
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 4.
Tu as remarqué que tu dis que tu n'as pas de problème avec gitlab, donc la charge administrative est faible. Par contre, pour les backups, on dirait que tu as politique différente.
Accessoirement, la réplication, ce n'est pas du backup.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par Psychofox (Mastodon) . Évalué à 6.
T'as pensé à faire un backup de ton détecteur de sarcasme aussi ?
[^] # Re: Pourquoi le feraient-ils ?
Posté par Michaël (site web personnel) . Évalué à 4.
Pas la peine, le code est facile à retenir:
[^] # Re: Pourquoi le feraient-ils ?
Posté par CrEv (site web personnel) . Évalué à 2.
Ok, mais en fait gitlab c'est facile si on a déjà toute l'infra derrière, matériellement et logiciellement plus des admins pour s'en occuper.
Donc en fait c'est exactement ce que je pointais, merci :-)
[^] # Re: Pourquoi le feraient-ils ?
Posté par Colin Pitrat (site web personnel) . Évalué à 4.
Et les tests de restore ? Tu n'en parles pas, pourtant c'est LA chose la plus importante. Parce-que des backups qui ne sont pas utilisables c'est incroyablement fréquent.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Nan, avec GitLab, c'est totalement impossible que les backups ne soient pas utilisables.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Kwiknclean . Évalué à 0.
Oui enfin ça ne fait qu'une VM à manger parmis d'autres, rien de bien sorcier et pas vraiment de boulot supplémentaire, lorsqu'on a déjà une infra de backup solide en place.
Suffit juste d'aller dire à Ton outil de backup que tu as une VM en plus à manger (S'il est pas trop vieux il le fait d'ailleurs tout seul sans que tu n'aies rien à faire de particulier).
[^] # Re: Pourquoi le feraient-ils ?
Posté par Kwiknclean . Évalué à 2.
Gitlab j'en sais rien mais Gogs et Gitea (le fork donc, que je viens de découvrir), c'est réellement 2 minutes montre en main.
Et ça fuse bon sang ! J'aimerais bien installer ça dans ma boutique.
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 10.
Le problème, ce n'est pas la configuration initiale. C'est, comme il s'agit d'un service critique à l'entreprise, qu'il faut des plusieurs personnes (qui ne peuvent pas être absentes en même temps) qui soient capable et disponibles pour le mettre à jour (surtout si c'est exposé sur internet, pour du télétravail ou des interactions avec les clients), pour debugger le jour où ça ne marche pas, pour intégrer avec telle ou telle autre appli/foncitonnalité.
Tout ça a un coût et ne sont pas forcément des compétences que tu as en interne.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par totof2000 . Évalué à 5.
A la limite, une boite qui développe du libre peut externaliser le code car de toute façon, celui-ci sera accessible tôt ou tard, d'une façon ou d'une autre, mais une boite qui développe son business model sur la propriété intellectuelle et sur du code fermé a intéret à investir dans ce genre de compétences, ou elle devrait changer de business model.
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 5.
Si le code est vraiment confidentielle, ça peut être vrai. Mais il y a plein de boîtes qui font du proprio sans que le code soit hautement confidentiel. Tant que les utilisateurs ne peuvent pas utiliser gratuitement le produit et les concurrents n'ont pas trop facilement accès aux algorithmes.
Prenons l'exemple de Photoshop. Si tu veux vraiment savoir ce qu'il fait, tu achète une licence et le décompile, donc ça ne sert à rien de blinder le code source. De plus, si tu as peur que ton sous-traitant vende le code, fais gaffe aussi à tous tes employés qui y ont accès qui peuvent, plus ou moins facilement, partir avec.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par Misc (site web personnel) . Évalué à 4.
Et encore, les algos, y a rarement rien de magique. Ce qui fait la valeur, c'est d'avoir passer du temps pour convertir une idée en code sans bug (ce qui en soit est une chose qu'on peut pas trop voler), mais la majorité des idées sont simples à exprimer.
Dans le cas de photoshop, ça va être l'interface, que tout le monde voit qui va être importante. Ça va être le fait d'avoir passer du temps à faire de quoi intégrer des plugins et à avoir un écosystème, chose qu'on ne peut pas voler non plus avec le code.
C'est aussi pour ça que le logiciel libre marche, parce qu'au final, avoir l'accès en lecture au code d'un soft, ça permet pas de faire un concurrent viable aussi rapidement. Avoir le droit de réutiliser, oui, avoir le droit de modifier/forker, oui. Mais pas la lecture. Et bon, quand on voit la tronche du code source libre moyen et le temps pour se plonger dedans, j'ose pas trop imaginer la tronche du code proprio moyen d'une PME sans la pression d'avoir du code un peu plus propre et lisible.
[^] # Re: Pourquoi le feraient-ils ?
Posté par totof2000 . Évalué à 6.
Comme je l'ai dit plus haut, le vol de code n'est pas le seul danger : une entreprise qui sait ce que tu déveloippes en interne peut adapter sa stratégie pour te passer devant, sans voler une seule ligne de code.
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 3.
Dans ce cas, on ne parle plus d'un vol de code généraliste mais d'un ciblage précis d'un concurrent direct de Microsoft, ça limite pas mal le cas d'usage où c'est problématique. Encore une fois, MS aurait accès à la roadmap de Photoshop que ça ne changerait pas grand chose.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par oinkoink_daotter . Évalué à 3.
Et encore. C'est toujours une histoire de bénéfice risque. C'est pas parce que c'est à "l'intérieur" que c'est correctement protégé. Les réseaux internes des entreprises sont fréquemment des désastres à tous les niveaux : réseaux internes mal segmentés, droits mal gérés, logiciels pas à jours et bien sur pas pas de sonde en sortie (ou dans) de réseau pour voir ce qui se passe. Sans compter qu'un laptop avec un clone d'une repo git sur un volume non chiffré qui se fait gauler, ça n'arrive pas qu'aux autres.
Donc du coup, même pour des trucs critiques ça peut être un choix de le mettre dehors. La vraie question, c'est plutôt, comme écrit ailleurs dans le thread, de savoir si l'hébergeur et/ou les pays qui ont prise sur l'hébergeur sont un risque crédible ou pas.
C'est pour ça qu'on paye des RSSI.
…
…
Je suis bien content de ne plus l'être :-D
[^] # Re: Pourquoi le feraient-ils ?
Posté par Michaël (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2018 à 19:44.
Je connais des gens qui utilisent toujours CVS. :-) Des gens qui font 4 Millions de CA.
[^] # Re: Pourquoi le feraient-ils ?
Posté par totof2000 . Évalué à 2.
Ca ne me choque pas à partir du moment ou CVS répond à leur besoin.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Benoît Sibaud (site web personnel) . Évalué à 7.
Encore ces nantis d'OpenBSD !
[^] # Re: Pourquoi le feraient-ils ?
Posté par Michaël (site web personnel) . Évalué à 4.
Ah ah excellent :) Je pensais bien-sûr à un de mes anciens employeurs.
Il y a une raison particulière pourlaquelle OpenBSD reste sous CVS au lieu de passer à subversion comme FreeBSD l'a fait il y a maintenant quelques années?
https://wiki.freebsd.org/VersionControl
[^] # Re: Pourquoi le feraient-ils ?
Posté par anaseto . Évalué à 5.
Une réponse d'un des développeurs (trouvée au hasard). En gros, ça marche et ça a les fonctionnalités dont ils ont besoin pour leur cycle de développement sans branches, tout le monde commite et teste sur le même truc.
[^] # Re: Pourquoi le feraient-ils ?
Posté par Moonz . Évalué à 4.
C’est justement quand tu commences à devoir debugger et intégrer que tu es content d’avoir internalisé un outil Open-Source plutot que d’être à la merci d’un presta externe bien plus gros que toi (c’est à dire pour qui ton bug/ta fonctionnalité est un ticket parmi des milliers qui sera prévu pour "dans une version ou deux, au mieux")
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 3.
Et du coup, tu vas devoir maintenir ton patch et gérer les effets de bord qu'il aura, sur la version actuelle et surtout sur les versions futures. Je ne dit pas que ce n'est pas faisable mais tu vas quand même dépenser beaucoup en temps pour ça, je ne suis pas sûr que ce soit rentable pour beaucoup de boîte. Comparer à payer pour corriger ce bug.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par Moonz . Évalué à 5.
Pour un bug, ton patch a de grande chances de venir de l’upstream, intégré dans la branche de dev pour la prochaine version, et tu veux juste l’appliquer en local parce que le bug en question est critique pour ton usage (ça m’est arrivé avec Gitlab)
Pour une fonctionnalité plus complexe, tu peux toujours balancer upstream pour pas avoir à maintenir.
Et cc’est sans compter que beaucoup de projets ont un système de plugins (Jenkins/Redmine me viennent en tête). Dans ma boite actuelle on a des plugins redmine développés en interne, bonne chance pour faire la même chose avec un tracker en mode SAAS.
Et sans compter que tout reste à l’intérieur de ton réseau. Je ne comprend toujours pas comment certains arrivent à tolérer qu’un service externe, sur un réseau externe, puisse se connecter sur leurs serveurs de production pour le déploiement (dans le cas où le déploiement se fait par un système de CI/CD externe).
[^] # Re: Pourquoi le feraient-ils ?
Posté par claudex . Évalué à 3.
Les SaaS ont un support où tu peux expliquer ton besoin et ils peuvent te mettre sur une instance patchée.
Si on prend redmine, il y a des offres avec plugin: https://plan.io/fr/tarifs/
À partir du moment où tes serveurs sont déjà à l'extérieur… Sans compter, qu'il y a plein de dev qui n'ont pas du code poussé directement sur des serveurs, par exemple des gens qui font de l'embarqué, des applications mobile ou desktop…
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Pourquoi le feraient-ils ?
Posté par Paul POULAIN (site web personnel, Mastodon) . Évalué à 6.
Témoignage garanti vrai: ce matin, LinkedIn me proposait les 4 influenceurs suivants : Bill Gates, Sadya Netella, Amazon et Oracle.
C'est plus qu'amusant, c'est caricatural !!!!
[^] # Re: Pourquoi le feraient-ils ?
Posté par Sufflope (site web personnel) . Évalué à 8.
Je sais pas si je dois être flatté ou vexé qu'il ne me recommande que Macron.
[^] # Re: Pourquoi le feraient-ils ?
Posté par oinkoink_daotter . Évalué à 3.
Ben si tu as un réseau et des activités dans la gestion des données, des infras, du logiciel, c'est pas forcément déconnant. Moi j'ai du avoir Macron et Bill Gates à un moment donné, mais à l'instant, il me propose si je vais voir dans les suggestions : Jacques Attali, Kofi Annan, Jessica Alba … et Loic Le Meur.
# Suite "logique"
Posté par davandg . Évalué à 9.
Microsoft a annoncé qu'il voulait, avec sa branche "Office", être l'acteur incontournable du monde de l'entreprise.
Github étant devenu un indispensable du monde de l'entreprise, c'est assez logique qu'il le rachète.
Cela ne m'étonnerais pas qu'ils achètent un (voir plusieurs) CRM. Peut-être pas SAP (qui coûte trop cher), mais sûrement des concurrents.
Ensuite, ils vont continuer de tout intégrer, doucement. Ils ont compris qu'intégrer trop rapidement pose des problèmes (rappelez-vous des difficultés lors du rachat de skype). Mais attendez-vous a pouvoir afficher vos "stars" dans votre profil linkedin, a recevoir un mail vous annonçant que votre compte github est devenu un compte microsoft et pouvoir éditer les docx dans github.
[^] # Re: Suite "logique"
Posté par steph1978 . Évalué à 3.
Déjà fait avec Dinamycs
# Politisation
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8.
Je suis pas sûr que ce soit le libre qui s'est dépolitisé. Il faut bien se rappeler du fonctionnement de Github: l'hébergement est gratuit pour les projets dont le code est public. Du coup, plein de gens profitent du service sans forcément s'engager dans le logiciel libre, et même sans forcément mettre de licence sur leur code.
C'était un peu différent sur Google Code à l'époque, qui était réservé aux projets libres (ils forçaient le choix d'une licence quand on créait un projet, parmi une liste assez restreinte). Mais donc sur Github, on a plein de gens qui sont juste là pour profiter d'un dépôt git, d'un bugtracker, d'un wiki et d'un hébergement web gratuits, en échange de laisser tout le monde voir leur code. Mais sans s'engager forcément dans une démarche de logiciel libre.
Est-ce que ça peut être suffisant pour faire découvrir le logiciel libre aux gens? Peut être. Ils auront la bonne surprise d'avoir des pull requests, ou la mauvaise d'avoir des rapports de bugs agressifs de gens qui veulent pas vraiment aider mais juste se passer les nerfs.
# Oui et ....
Posté par azerttyu (site web personnel) . Évalué à 2.
… c'est un service décentralisé
Le gros avantage de git c'est qu'il propose de base un écosystème distribué/décentralisé. Il est donc simple est facile de migrer ses dépôts d'une forge à une autre.
En tant qu'utilisateur la valeur ajoutée d'une plateforme telle que github c'est paradoxalement la centralisation des dépôts et son aspect réseau social (comme la vision centralisée des projets, PR, fork, …)
Premier cas, rien ne change dans le fonctionnement de github et dans ce cas rien ne change pour les utilisations lambda.
Second cas github coupe la partie "sociale" on a 2 options :
* une autre opérateur prend la relève, et il y a déjà des outsiders comme gitlab.com
* il y a un éclatement sur plusieurs forges (centralisées et/ou autohébergées; gitea, gogs, gitlab, phabricator, …)
A noter que les différentes forge proposent une api globalement équivalentes, github a imposé son modèle et il a depuis peu évolué.
Même dans le cas d'un éclatement des forges, il est tout à fait possible de voir venir un service "social" qui reprendrait les aspects exploration, centralisation (dans la veine d'openhub).
En pratique cela ne va pas changer grand chose. Au pire il faudra faire des regexp pour remplacer github par son remplaçant :)
[^] # Re: Oui et ....
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Il y a le souci quand même de l'export/import des tickets. Ça se fait, mais pas si facilement. Et les tickets, c'est tout aussi important que le code source, ça fait parti de l'historique du projet, mais aussi de la gestion du projet.
[^] # Re: Oui et ....
Posté par Jérôme Flesch (site web personnel) . Évalué à 5.
Et le wiki (même si GitHub le stocke comme un dépôt Git).
Et, encore plus compliqué à migrer, la visibilité: J'ai un projet avec >2000 étoiles sur Github. Bien classé dans les résultats de recherche GitHub (et dans une moindre mesure dans les résultats Google&co). Si j'efface les dépôts de GitHub, je vais perdre cette visibilité.
[^] # Re: Oui et ....
Posté par Misc (site web personnel) . Évalué à 3.
Et l'intégration avec travis et autre trucs. travis-ci est un logiciel libre, mais je connais personne qui l'utilise en dehors du service hosté.
Github a un écosystéme assez important de services tiers (couverture de code, verification des dependances), et les gros projets contournent l'UI de github via des bots (par exemple, kubernets, ansible, openshift, rust) qui se base tous sur les APIs de github. C'est aussi des choses à migrer.
Enfin, la migration des tickets, c'est bien joli, mais les tickets sont liés à un compte, donc il faut aussi ajouter une migration de l'authentification à tout ça. Ou juste perdre les tickets, mais curieusement, les gens aiment pas ça et y a toujours des gens pour dire "quoi, j'ai passé 5 minutes y a 7 ans pour écrire un texte, je vais pas repasser 10 minutes à le recopier, il faut que le projet s'en occupe", cf les discussions sur la migration de gnome à gitlab).
[^] # Re: Oui et ....
Posté par Albert_ . Évalué à 2.
Gitlab permet d'importer les "issues" mais cela perd l'auteur du ticket (forcement) et tout est reaffecte a celui qui a importe.
# Github n'est pas libre…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
… et le fait qu'il soit racheté par Microsoft ne le rends pas plus, ni moins libre.
En conséquence, je m'étonne un peu de la logique de ceux qui disent que maintenant ils vont migrer vers autre chose – même si c'est probablement une bonne chose s'ils migrent vers une solution libre.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Github n'est pas libre…
Posté par claudex . Évalué à 5.
gitlab.com n'est pas libre non plus. Donc, ça ne me choque pas que les gens changent en fonction du propriétaire, vu qu'ils ne changent pas pour un service utilisant du libre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Github n'est pas libre…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 2.
GitLab a la réputation d'être libre (et il l'est en partie). J'imagine que ça joue aussi.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Github n'est pas libre…
Posté par Jérôme Flesch (site web personnel) . Évalué à 10.
Dans mon cas spécifiquement, c'est juste un problème de réputation de chaque entreprise:
[^] # Re: Github n'est pas libre…
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à -3.
ça a bien changé chez Microsoft ces derniers temps.
[^] # Re: Github n'est pas libre…
Posté par ff9097 . Évalué à 5.
Et ça peut changé à nouveau
[^] # Re: Github n'est pas libre…
Posté par steph1978 . Évalué à 4.
Le problème est que github n'avait pas coûté 7Md.
Et donc n'avait pas le même enjeu commercial que maintenant dans les mains de redmond.
[^] # Re: Github n'est pas libre…
Posté par Kwiknclean . Évalué à 0.
Ca me fait tout de même bizarre de lire ce genre de commentaires plutôt tendre avec Microsoft sur Linuxfr …
[^] # Re: Github n'est pas libre…
Posté par CrEv (site web personnel) . Évalué à 7.
C'est certain que c'est différent des commentaires classiques.
Je sais que beaucoup ne vont pas aimé ce genre de commentaire, mais tant pis ;-)
https://twitter.com/kellabyte/status/1003660575690244096
Après, libre à chacun d'y croire ou non, il est aussi absolument certain que Microsoft ne fait toujours pas tout en open source. Moi ce que je note c'est que le discours a clairement changé. On peut faire comme si ça n'avait aucune influence, comme si c'était juste un discours et que derrière ils allaient entuber tout le monde. Ou on peut laisser une chance.
C'est assez marrant, il y a quelques années tout le monde se plaignait que Microsoft n'en avait rien à faire du libre, de linux. Maintenant ils annoncent qu'ils aiment linux, embauchent des devs qui viennent et croient au libre, ils ouvrent une partie de leurs développement, intègrent des couches linux dans windows, etc. C'est sur que ça n'en fera pas un RedHat en claquant des doigts, mais je trouve le changement assez impressionnant pour une boite qui doit avoir une énorme inertie.
Et quand on compare avec Google qui avait une bonne image dans le monde libre et linux et qui semble la perdre petit à petit, ça peut faire réfléchir.
Après je dis ça, je suis pas passé pour autant sous windows, je suis au contraire revenu sous linux full time après quelques années sous mac :-p
[^] # Re: Github n'est pas libre…
Posté par Kwiknclean . Évalué à 4.
Ce n'est pas tant cette "adhésion" au logiciel libre qui me fait m'interroger, c'est très bien que tout ceci aille dans ce sens qu'ils embrassent le libre et consort (soit) … quand bien même Windows 10 semble rester une véritable cafteuse, qu'ils pratiquent toujours la vente liée (qui faisait hurler tout le monde il y a quelques années) maintenant cela semble être du détail, désormais ils font du libre ils sont clean ces gens là. Comme si faire du "libre" était le marqueur d'une éthique désormais impeccable.
Le soucis reste bien le même la centralisation, et ça j'ai l'impression que beaucoup l'oublie ou font mine de pas le voir, c'est un sujet pour le moins sensible.
Le fait que 4 ou 5 acteurs se partagent l’intégralité de l'écosystème Internet doit et devrait amener à se poser des questions (qu'il s'appelle Google, Apple, Amazon, Microsoft, Inserer un ou deux Chinois montant … la n'est pas la question).
Cela ne me semble pas être une démarche allant dans le sens d'un Internet libre et ouvert, décentralisé, vive le retour au Mainframe au client léger au Minitel.
Biais cognitive me concernant que je n'arrive pas à saisir, de l'avis générale, la Data est une forme d'or numérique du 21éme Siècle, avec l'émergence des travaux de traitement de big-data d'analyse de données et consort, cette manne de données constitue une véritable ressource à la plus-value encore sous exploitée.
En parallèle il y a cette volonté globale de tout mettre chez AWS ou Azure, quelle est la logique ? Faire des économie, oui on a saisit, la course au toujours moins cher et ensuite sous 5/10 ans ?
Avoir la main sur toutes ces data les rend extrêmement puissant, le fait qu'ils ne soit que quelques-un vraiment problématique.
Miser sur le fait que "chiffrer" ses données pour externaliser chez ces entités, me parait tout à fait naïf. Ces structures ont la capacité de conserver tout ceci sur des années voir des dizaines d'années durant. Et seront sans aucun doute les premiers à pouvoir s'offrir le matériel adéquate (ordinateur Quantique ?!) pour venir casser les algos de chiffrement le moment venu si l'envie leur en dit ou sur la demande qu'un quelconque gouvernent.
Quelle est le risque de confier cette ressource à des entités mondes comme ces entreprises ? Je considère qu'il est non nul. Je considère qu'on ne peut avoir confiance (l'histoire l'a mainte fois prouvé), les monopoles ne vont jamais dans notre sens !
Ou alors je vis pas dans le même monde et Prism n'a jamais existé, les DC de la NSA plugués un peu partout, n'ont jamais existé, Xkeyscore n'a jamais existé, Snowden est illuminé, Reflet.info est un site de complotiste .. LinuxFR est soumis à la Troïka ;0
[^] # Re: Github n'est pas libre…
Posté par Lutin . Évalué à 5.
Mouais, est-ce qu'on disposera encore d'assez de ressources pour fabriquer, ou juste maintenir, un ordinateur dans quelques dizaines d'années ?
[^] # Re: Github n'est pas libre…
Posté par voxdemonix . Évalué à 4. Dernière modification le 07 juin 2018 à 12:24.
C'est juste du marketing, comme quand n'importe quelle multinationales fait sa propagande/pub. Ils continuent leur rente a coups de brevet, a magouiller dans nos pays pour obtenir des contrats, a forcer la vente lié, a bloquer la concurrence avec ses logiciels/services (voir l'intégration forcée de dropbox et les bugs volontaire des montages webdav).
[^] # Re: Github n'est pas libre…
Posté par Psychofox (Mastodon) . Évalué à 5.
C'est pas vraiment ça le problème. Ce qu'on dit c'est que si tu utilisais github avant, c'est que t'étais pas contre utiliser du proprio et que tu faisais confiance à quelqu'un qui était prêt à vendre sa boite à Microsoft. Que tu le saches ou pas qu'ils le feraient ne changent rien à l'histoire. À tout moment tu n'avais aucune maitrise de où étaient hébergées tes données, qui y avait accès réellement et si ces données seraient hébergées dans le futur par MS, Alphabet, Facebook, Oracle, Amazon ou une mafia quelconque.
Bref rien n'a changé dans la confiance que tu pouvais avoir tant en github qu'en Microsoft.
[^] # Re: Github n'est pas libre…
Posté par Kwiknclean . Évalué à 0.
"Ce qu'on dit c'est que si tu utilisais github avant".
Je ne suis pas dans ce cas là, j'ai donc les fesses propres ;-)
Je n'ai jamais créé de repo Github, c'était bien trop mainframe/minitel pour moi.
Je m'auto-herberge au maximum, vraiment, hormis la messagerie que je trouve trop compliqué et lourde à administrer …
J'ai mon instance Gogs sur mon nom de domaine, c'est parfait pour mes projets, n'ayant pas besoin de la visibilité ne développant pas de super outils avec plein d'étoiles servant la communauté ça me suffit largement. Je m'en sers pour stocker mes fichiers de conf, des usage un peu détourné de déploiement automatisés …
Après je évidemment me mets à la place des dirigeants de Github, si Microsoft vient toquer à ma porte avec un petit chèque de 7 Milliards bon .. c'est pas que je sois vénal mais une somme pareil ça fait évidemment réfléchir deux minutes.
Comme l'a fait très justement remarqué une personne Github était déjà quelque part dans le cercle GAFAM avec cette hyper-centralisation, la chose est désormais officialisée.
# Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Lawless . Évalué à 7.
Microsoft ne clame pas qu'il aime le logiciel libre, Microsoft clame qu'il aime Linux, c'est différent et c'est juste un discours marketing. Je ne pense pas que Microsoft soit un adepte du logiciel libre, des idées de Richard Stallman ni de la liberté des utilisateurs selon la FSF. Par contre Microsoft utilise l'open source pour attirer des contributeurs sur ses projets. Microsoft contribue-t-il à des projets autres que ses propres projets ? Mis à part des patchs sur le noyau Linux pour améliorer le fonctionnement de Linux sur sa plate-forme Azur, je ne vois pas. Logiciel libre et open source ce n'est pas vraiment la même chose.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Tu devrais aller faire un tour sur le compte Github de Microsoft…
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Colin Pitrat (site web personnel) . Évalué à 3.
Si ça se trouve, Microsoft va même libérer le code de github … Wait & see 😀
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par CrEv (site web personnel) . Évalué à 2.
Le Microsoft d'aujourd'hui n'est clairement pas le même qu'il y a quelques années.
Microsoft embauche beaucoup de monde pour bosser activement sur Go, sur kubernetes (oui on trouve réellement des offres Microsoft qui disent "venez pour bosser upstream sur kubernetes") par exemple.
Donc sur des projets open source, des gros projets, initiés par leurs concurrents, et pour bosser upstream, pas sur un fork interne.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Jérôme Flesch (site web personnel) . Évalué à 10. Dernière modification le 04 juin 2018 à 11:07.
Questions que je me pose:
Pour Kubernetes, ne s'agit-il pas juste d'ajouter et maintenir le support des containers Windows ainsi que de supporter Kubernetes par dessus Azure ? Pour Go, ne s'agit-il pas juste de le supporter dans Azure ?
Si oui, qu'est-ce qui indique que Microsoft ne suit pas juste sa stratégie habituelle de EEE ?
Pour l'instant, tel que je vois ça, il ne s'agit pas forcément de réelle coopération. Il est possible qu'ils tentent maintenant d'appliquer simplement le EEE aussi aux projets opensource.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Sacha Trémoureux (site web personnel) . Évalué à 3.
Comme Google quoi.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par CrEv (site web personnel) . Évalué à 4.
Juste comme ça, quand bien même ce serait pour faire tourner k8s et azure ensemble, le faire de manière ouverte, upstream, c'est à dire embaucher des gens pour contribuer à un projet open source d'envergure, n'est pas "une réelle coopération"?
Si c'est le cas alors c'est juste exactement la même chose pour tous les projets open source portés par une boite, Gitlab avec sa version closed source n'est pas une réelle coopération par exemple.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Jérôme Flesch (site web personnel) . Évalué à 4. Dernière modification le 04 juin 2018 à 11:35.
qu'il me semble que les contributions se concentrent essentiellement sur faire marcher les outils open-source (k8s, etc) avec les outils fermés de Microsoft (Azure, etc). Ce qui rend possiblement dépendant des outils fermés, et ce qui correspond très bien à la partie "Embrace" et "Extend".
Concernant Gitlab, la différence avec Azure, c'est que tu peux héberger une instance Gitlab open-source sur ton réseau. Tu ne pourras pas héberger une infrastructure Azure sur ton réseau.
Parce-que Gitlab est au moins en parti open-source, si tu t'auto-héberges, tu pourras toujours récupérer toutes tes données. Pour Azure, je ne sais pas ce qu'il en est à l'heure actuelle, mais je peux déjà dire ce qu'il en sera si Azure arrivait à prendre plus de 90% du marché cloud.
Autrement dit, avec un auto-hébergement GitLab, tu sais que tu pourras toujours être maître de tes données. On est donc clairement plus dans un objectif de coopération avec le client que dans un objectif de le capturer.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Psychofox (Mastodon) . Évalué à 4.
Azure Stack: azure services on-premises
Tu disais ?
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Jérôme Flesch (site web personnel) . Évalué à 4.
Ah bien vu.
Ceci dit, il s'agit de code propriétaire ==> le problème d'enfermement du client reste exactement le même (cf Windows, Office, etc).
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Psychofox (Mastodon) . Évalué à 6.
ouais bon si tu utilises autre chose que le gitlab "community" on-premise, c'est pareil t'es sur du proprio. Et tu peux encore remercier gnome pour avoir fait pression pour que le support du ldap soit dans la version libre, avant ce n'était pas le cas.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par CrEv (site web personnel) . Évalué à 6.
Et si tes données sont liées à une partie non libre de gitlab ?
Vraiment ? Tu sais déjà ce que ça donnerait ? Tu peux nous éclairer ?
Franchement il y a une quinzaine d'année je n'aurais jamais cru que Microsoft ouvrirait des morceaux entiers de .Net, serait un gros contributeur open source, aurait ouvertement une distribution linux, embaucherait des figures du libre et du monde linux, bosserait ouvertement upstream sur des projets d'envergure. Bref j'aurais eu tout faux, mais peut-être est-ce juste moi.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Jérôme Flesch (site web personnel) . Évalué à 5. Dernière modification le 04 juin 2018 à 13:42.
Game over. C'est toujours le risque avec le propriétaire. Le secret, c'est de ne pas se rendre dépendant des parties non-libres :-)
Facile. Exactement ce qui s'est passé avec Windows, LDAP/Active-Directory, Office, Internet Explorer, etc: "Extinguish" ; Ajouts d'incompatibilité avec les autres fournisseurs, complexification, développement de fonctionnalités totalement spécifiques à Microsoft, méthodes commerciales anti-compétitives, et j'en passe.
Oui, on avait de la chance à cette époque. Steve Ballmer était trop bête pour voir que la stratégie EEE s'applique très bien aussi aux projets open-source. Ça demande juste beaucoup plus de temps.
Je suis peut-être parano, mais pour une société comme Microsoft, il m'a toujours semblé que l'argent était la finalité. Et le meilleur moyen de faire un maximum d'argent en investissant le moins possible, c'est de rendre ses clients dépendants. À noter que ce raisonnement s'applique à toutes les entreprises. C'est juste que beaucoup n'ont simplement pas l'opportunité de le faire.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Tu connaît des entreprises qui ne cherchent pas à gagner de l'argent peut-être?
C'est évident qu'ils vont aller là ou il y a des sous à gagner. Comme tout le monde. Ils peuvent le faire soit en détruisant tout sur leur passage, soit en essayant de collaborer avec le reste de l'écosystème (du technosystème?) et en construisant quelque chose de durable. En ce moment ils sont plutôt dans la deuxième approche. Ce qui n'en fait pas des bienfaiteurs de l'humanité, hein.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Jiel (site web personnel) . Évalué à 4.
C'est la finalité de la plupart des sociétés. Une société n'est pas une administration, ni un service public, ni une association à but non lucratif. Cela ne veut pas dire que les entreprises sont inutiles ou nuisibles, mais le but dans notre système économique c'est avant tout de gagner de l'argent.
Cela ne remet pas en cause le reste de ton propos. Il y a différentes façons d'avoir des clients, soit en offrant un service performant et innovant (Red Hat?), en étant en situation de monopole (SAP, Oracle?), en ayant des clients captifs (Microsoft?) ou en ciblant un public particulier (Apple). Toutes ses méthodes fonctionnent, certaines entreprises cumulent ces méthodes ou passent de l'une à l'autre au cours du temps.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par pasBill pasGates . Évalué à -2.
Non non, le mot "peut-être" n'a pas lieu d'être dans cette phrase, c'est certain.
Faut sortir de ta cave, on n'est plus en 2003, on est en 2018, la plupart des gens qui étaient dans les hautes sphères de MS sont parties. La boite n'est plus la même.
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par totof2000 . Évalué à 1.
Bah, d'autres peuvent revenir à leur place. Dans la même veine, qui aurait pu dire il y a trois ans, que les US iraient surtaxer l'acier importé par ses partenaires ?
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par pasBill pasGates . Évalué à 2.
Ah mais ce que tu dis est totalement vrai !
C'est vrai pour toutes les sociétés, toutes les fondations, …
Bref, il ne faut faire confiance à personne, et toujours tout faire en interne suivant ce modèle. On va aller loin comme ça…
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Misc (site web personnel) . Évalué à 6.
Non, parce que les gens en interne peuvent aussi être ceux dont tu te méfies pour aller dans les autres boites :)
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par oinkoink_daotter . Évalué à 2.
T'as jamais bossé avec un service partagé, toi :-D
[^] # Re: Microsoft ne clame pas qu'il aime le logiciel libre.
Posté par Misc (site web personnel) . Évalué à 6.
Oui, ça s'appelle l'interopérabilité. Le souci n'a jamais été sur ça, parce que c'est la partie saine. Le souci est sur le 3eme E, Extinguish. Je trouve ça tellement surréaliste de voir des gens râlé sur l'interopérabilité.
Et à ce niveau, j'aimerais aussi rappeler que c'est pas uniquement Microsoft qui fait ça, meme si c'est sans doute les plus connus car les premiers/plus gros à l'avoir fait (et à avoir réussi). Par exemple, on peut rajouter Google pour ça, Facebook aussi.
# +1 pour Microsoft
Posté par SRL . Évalué à 10.
Grâce à Microsoft, les gens commencent enfin à se rendre compte que Github avait tout ce qu'il faut pour rentrer dans la case GAFAM (maintenant, c'est un GAFAM). S'il n'y avait pas une telle centralisation, peut-être que Microsoft ne se serait jamais intéressé à Github.
Les gens ferment peut-être leurs comptes, mais les données persistent et appartiennent désormais à Microsoft.
# Je le savais
Posté par David Demelier (site web personnel) . Évalué à -6. Dernière modification le 04 juin 2018 à 13:03.
Je le savais que ça allait arriver. J'héberge mes dépôts Mercurial depuis 10 ans et on m'a demandé des dizaines de fois « toujours réfractaire à Git et Github ? », maintenant toutes ces personnes ont leur réponses.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je le savais
Posté par Renault (site web personnel) . Évalué à 10.
Rien à voir avec la choucroute, tu pouvais et tu peux encore auto héberger ton dépôt Git… La question de Github n'a aucun impact sur Git lui même.
[^] # Re: Je le savais
Posté par David Demelier (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2018 à 14:12.
Je ne compare pas Git / GitHub / Mercurial, je parle simplement du fait de ne pas héberger un projet chez un tiers.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je le savais
Posté par Guillaume Denry (site web personnel) . Évalué à 8.
Du coup, pourquoi préciser que tes dépôts sont en mercurial et que tu es réfractaire à Git ? Tu mélanges pas un peu tout là ?
[^] # Re: Je le savais
Posté par Sufflope (site web personnel) . Évalué à 4.
Bah pourtant…
Tu pouvais héberger tes dépôts git, hein…
Ou alors tu voulais dire que ces personnes ont leur réponse sur la partie "github" de la question, mais alors la formulation est assez malheureuse.
[^] # Re: Je le savais
Posté par David Demelier (site web personnel) . Évalué à 0.
Je parle simplement de l'autohébergement.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Je le savais
Posté par chimrod (site web personnel) . Évalué à 2.
Ça ne change rien : tu peux très bien héberger ton dépôt git (Si tu souhaites juste diffuser ton repo, sans chercher à y intégrer un système de bug, sinon c'est plus compliqué)
# Et avec Github...
Posté par rdhlnn . Évalué à 5.
Microsoft acquiert Atom et Electron…
[^] # Re: Et avec Github...
Posté par Pinaraf . Évalué à 10.
Et tout le monde abandonne Electron ? Alors là je dis oui, oui oui et re-oui !
[^] # Re: Et avec Github...
Posté par Misc (site web personnel) . Évalué à 2.
Je doute que ça arrive. La raison d'utiliser electron, c'est bien parce que c'est 1) cross platform 2) en js.
Cross platform, c'est grosso modo requis, même si en général, ça veut juste dire "windows et mac os x" d'un point de vue des parts de marché.
Et le fait d'être en js permet de reprendre une partie du code existant (ce qui réduit les couts), fait que tu as moins de difficulté à trouver des gens qui connaissent le langage, avec une expertise en interne existante (au moins pour les boites qui font des services webs).
Donc non, je doute que tant qu'il y a pas un truc qui réponds à ces 2 besoins, ça va pas arriver. Et AMHA, c'est pas le fait de devoir faire des mises à jours de temps en temps qui va contre balancer ces impératifs économiques pour une boite.
[^] # Re: Et avec Github...
Posté par kursus_hc . Évalué à 5.
Oui et comme ça le moindre plugin rend la chose inutilisable.
[^] # Re: Et avec Github...
Posté par Claude SIMON (site web personnel) . Évalué à 2. Dernière modification le 04 juin 2018 à 16:00.
Juste par curiosité, c'est quoi le problème avec Electron ?
Ce n'est pas la première fois que je vois des commentaires suggérant qu'Electron présente quelques défauts rédhibitoires, mais sans préciser lesquels. Et, vu la note du commentaire, ça à l'air d'être un avis assez répandu.
Je l'utilise (pas de manière classique, il est vrai), ainsi que des logiciels qui s'appuient dessus, et je dois avouer que je ne vois pas trop quel est le problème avec Electron…
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Et avec Github...
Posté par David Demelier (site web personnel) . Évalué à 10.
Electron embarque le moteur de chromium. Donc chaque application démarre autant de ressources que chromium. Le pire c'est que maintenant on s'attaque à des applications encore plus banales.
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Et avec Github...
Posté par MrBidon . Évalué à 3.
Le top étant les applis electron pour Android…
[^] # Re: Et avec Github...
Posté par Claude SIMON (site web personnel) . Évalué à 1.
D'après wikipedia :
Donc, à priori, ça ne paraît pas illogique qu'il s'appuie sur un navigateur web.
Partant de là, si j'ai bien compris, ceux qui sont réfractaires à Electron, ils le ne sont pas à Electron en lui-même, mais, de manière général, au principe d'utiliser des technologies web pour développer des applications bureau (ou Android). Me goure-je ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Et avec Github...
Posté par Dr BG . Évalué à 10.
Ou peut-être réfractaire à l'utilisation de techno lourdes et pas intégrées pour développer des applications de bureau, comme à la bonne époque des Adobe Air, même si libre.
[^] # Re: Et avec Github...
Posté par Misc (site web personnel) . Évalué à 8.
Disons qu'il y a le fait que ça consomme pas mal de ressources, surtout si chaque application vient avec son interpreteur, qui va faire sa propre compilation en jit sans garder les ressources en commun. Le JIT, comme pas mal de chose c'est un choix entre gagner du CPU en perdant de la mémoire. Et donc ouais, les applis electrons vont bouffer une tonne de ram. Et parfois aussi une tonne de cpu quand même…
Ensuite, y a le fait qu'electron, de part sa nature, vient avec son jeu de failles spécifiques peu courante sur le desktop (genre xss, etc).
Voir par exemple: CVE-2018-10994 (https://ivan.barreraoro.com.ar/signal-desktop-html-tag-injection/ et https://thehackerblog.com/i-too-like-to-live-dangerously-accidentally-finding-rce-in-signal-desktop-via-html-injection-in-quoted-replies/index.html ).
Enfin, comme chacun embarque son bout de chromium, c'est pas sur d'avoir un chromium à jour et on arrive avec d'autres soucis de sécurité lié à ça (même si la majorité sont sans doute pas applicable).
Et comme chaque app embarque son propre Electron, bah quand tu as un truc comme CVE-2018-1000006 , c'est pas top vu que faut que tout soit à jour.
Et le souci, c'est pas d'avoir des failles en soi. C'est du js, donc tu as pas de buffer overflow ce qui est pas mal. C'est plus que par la nature du framework et de la facon dont les gens utilisent ça, tu as des soucis. Et c'est aussi le fait que ce genre de souci sont bloqué par les browser (xss auditor, par exemple), par les serveurs webs (mod security), mais qu'il y a rien sur le desktop, ce qui est pas terrible.
Ensuite, y a sans doute aussi un peu de mauvaise foi, parce qu'aucune technologie n'est parfaite, mais si une techno est populaire, il va forcément avoir plus de gens qui râlent sur ça.
[^] # Re: Et avec Github...
Posté par Thierry Thomas (site web personnel, Mastodon) . Évalué à 10.
Un autre point à noter sur Electron ou Atom : c’est Open Source, mais la difficulté de le compiler est telle que tout le monde en est réduit a installé un binaire, comme pour une vulgaire application commerciale. Quelqu’un voulait un portage natif sur FreeBSD, alors j’avais regardé : c’est l’horreur, déjà rien que pour récupérer les sources ; il faut prévoir des Gio d’espace disque, des procédures de compilation baroques, etc. Bref, même si c’est théoriquement possible (on a un port de chromium, avec une foultitude de patches), j’ai abandonné, et d’autres aussi.
[^] # Re: Et avec Github...
Posté par El Titi . Évalué à 2.
Qui mieux que les inventeurs d'Electron pourraient répondre à ta question ?
Du coup, il se sont inspirés de Mozilla pour refaire un truc qui tient la route avec un langage qui ne prend pas l'eau ;-) … Rust et une couche de rouille pour épater la galerie en JS:
https://github.com/atom/xray
[^] # Re: Et avec Github...
Posté par Pinaraf . Évalué à 10.
On se retrouve avec des "applications" terriblement lentes par rapport aux applications natives. Sur slack par exemple, il m'est arrivé d'attendre une seconde entre ma frappe au clavier et l'affichage dans le champ d'écriture de message. Je ne parle pas de l'envoi hein, juste l'affichage du message en cours de rédaction.
Et je ne vais pas parler de la consommation de RAM. Mon PC a 8GB de RAM, ce n'est pas pour la gâcher avec chaque application qui bouffe la RAM d'une instance de navigateur web.
On prend un afficheur de documents et on le transforme en plateforme d'exécution d'applications… Tout va bien ?
[^] # Re: Et avec Github...
Posté par Claude SIMON (site web personnel) . Évalué à 0.
Les applications web, c'est le même principe, me semble-t-il. Faudrait-il donc les bannir également ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Et avec Github...
Posté par vv222 . Évalué à 9.
Je suis développeur Web de métier, et je réponds oui.
Mais plus sérieusement, les applications Web ne lancent pas toutes leur propre instance dédiée du navigateur. Les applications Electron si.
[^] # Re: Et avec Github...
Posté par Pinaraf . Évalué à 9.
Je pense que j'étais assez explicite précédemment : je bannis les applications web de ma machine, effectivement. Je préfère Marble à * Maps, mon client Slack en Qt au client Slack web, KMail à GMail, LibreOffice à Google Doc…
[^] # Re: Et avec Github...
Posté par Albert_ . Évalué à 5.
Quel est le nom de ton client Qt pour Slack? Ca m'interesse surtout si tu peux avoir plusieurs channel slack dessus :)
[^] # Re: Et avec Github...
Posté par Pinaraf . Évalué à 7.
Il s'appelle NotReleasedYet :)
J'ai prévu de faire un journal sur ça d'ici quelques semaines, le temps de stabiliser et d'implémenter assez de fonctionnalités pour que ça soit «montrable» sans honte…
[^] # Re: Et avec Github...
Posté par Claude SIMON (site web personnel) . Évalué à 1.
Du coup, Atom va-t-il être abandonné, vu qu'ils ont déjà VS Code ?
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: Et avec Github...
Posté par rdhlnn . Évalué à 2.
Sans doute forké (par Gitlab ? Ils aiment bien copier Github, donc on ne sait jamais… Plus sérieusement, peut-être par quelques développeurs actuels pour rendre le projet indépendant), et après du côté de Github (nouvelle direction), peut-être abandon du projet Atom et convergence vers VS Code (en reprenant les fonctions intéressantes de Atom, manquantes dans VS Code).
Et pour Electron… NW.JS ? En tout cas, la tendance va sans doute rester du côté de javascript.
[^] # Re: Et avec Github...
Posté par Yuul B. Alwright . Évalué à 3.
J'utilise Emacs. \o/
D'ailleurs je vais tester la version 26.1 qui est sortie l'autre jour.
[^] # Re: Et avec Github...
Posté par Tonton Th (Mastodon) . Évalué à 2.
Et c'est
BBCla prochaine étape ?# FusionForge 6.1 à tester ?
Posté par franck villaume (site web personnel) . Évalué à 1.
C'est peut-être l'occasion de faire un peu de pub pour FusionForge. https://fusionforge.org/projects/fusionforge/
N'hésitez pas à tester, etc. A la différence des autres forges (type gitlab), il n'existe pas de version "Enterprise" ou propriétaire de FusionForge. C'est 100% libre, … et cela depuis 20 ans.
Et pour tester, rien de mieux que l'image docker:
https://fusionforge.org/plugins/mediawiki/wiki/fusionforge/index.php/Docker
[^] # Re: FusionForge 6.1 à tester ?
Posté par Zenitram (site web personnel) . Évalué à 6.
Soit bien avant GitLab, mais GitLab a plus de succès. "N'hésitez pas à tester", hum… Faudrait donner des arguments pour donner envie, "depuis 20 ans" ne donne pas envie.
Note : j'ai regardé juste la partie licence, GitLab et FusionForge sont certes tous les 2 libres, mais l'un est copyfree et l'autre copyleft, et perso (c'est très perso, aucun reproche à d'autres qui ont d'autres priorités, et ça ne rend pas l'autre moins libres, ils sont autant libres l'un que l'autre) je priorise largement les projets qui me laissent le plus de libertés (et surtout moins de galères de gestion de licence), donc bon à première vue la comparaison commence mal pour l'outsider proposé.
GitLab t'autorise à concurrencer exactement leur business model avec les mêmes armes si tu penses faire mieux qu'eux, ils ne gardent pas une liberté pour eux seuls afin de t’empêcher de les concurrencer, donc je ne vois pas en quoi ce serait un point négatif.
Chacun ses priorités certes, mais perso un "N'hésitez pas à tester" suivi d'un logiciel X pas le plus connu, je trouve ça chiant, un peu d'argumentation que diable, montrez que vous y croyez avant de faire perdre du temps aux autres!
PS : ça marche aussi pour ceux qui disent quitter GitHub suite à l'achat, beaucoup de "Microsoft ça pue", mais après pour avoir de vraies raisons… GitHub n'a pas changé, on savait que ça pouvait arriver un jour, à voir si la création de repos sur GitLab va tenir sur du long terme ou si les gens ne vont juste pas rester avec GitHub en principal et laisser leur repo GitLab en miroir.
[^] # Re: FusionForge 6.1 à tester ?
Posté par Jiel (site web personnel) . Évalué à 10.
Ne pas faire confiance à une entreprise ou ne pas l'aimer est déjà une bonne raison de migrer. Microsoft a tout un historique, ce n'est pas une entreprise comme une autre. Microsoft, c'est TCPA Palladium/Next-Generation Secure Computing Base, c'est l'affaire SCO, c'est un monopole maintenu à coups de pratiques illégales (pressions sur les fabricants de matériel, corruption d'administration), c'est des tas de problèmes concernant la vie privée. Sans compter la qualité technique de ses produits qui n'est pas toujours au rendez-vous.
# Mème
Posté par windu.2b . Évalué à 6.
Je me dépêche de vous faire profiter de ce mème, tant qu'on en a encore le droit :
# Et bitbucket ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Tout le monde ici discute de gitlab mais je m'étonne que personne ait cité bitbucket
[^] # Re: Et bitbucket ?
Posté par RyDroid . Évalué à 5.
BitBucket n'a aucune version libre (alors qu'il y a la Community Edition pour GitLab) et n'est pas auto-hébergeable (alors que GitLab CE a même un paquet Debian officiel pour rendre la chose triviale). De plus, il me semble qu'il n'a pas de CI (Continuous Integration).
# Alternatives gratuite et moderne
Posté par voxdemonix . Évalué à 1. Dernière modification le 04 juin 2018 à 14:54.
Quelles alternatives gratuites, modernes (*1) et sans prise de tête conseilleriez-vous pour quelqu'un qui déteste Microsoft ? (sans auto-hébergement)
*1 moderne dans le sens UX Design et application android
[^] # Re: Alternatives gratuite et moderne
Posté par Jérôme Flesch (site web personnel) . Évalué à 4.
Proposition: Framagit (instance GitLab de Framasoft)
[^] # Re: Alternatives gratuite et moderne
Posté par voxdemonix . Évalué à 2.
Aucun risque que le service soit coupé comme avec framapics?
[^] # Re: Alternatives gratuite et moderne
Posté par Sufflope (site web personnel) . Évalué à 4.
Si tu as peur de ça pourquoi ne pas aller sur l'instance de gitlab eux-même ?
[^] # Re: Alternatives gratuite et moderne
Posté par voxdemonix . Évalué à 1.
Remarque fort pertinente. J'avais mal lu l'onglet pricing :)
[^] # Re: Alternatives gratuite et moderne
Posté par RyDroid . Évalué à 4.
Parce qu'il y a Microsoft derrière ?
https://linuxfr.org/users/superzen/journaux/microsoft-rachete-github#comment-1741105
https://framasphere.org/posts/5135816
Et peut-être demain Google ?
https://linuxfr.org/users/superzen/journaux/microsoft-rachete-github#comment-1741106
https://jobs.lever.co/gitlab/a9ec2996-b7b6-4d87-aed0-1fc2ce3f8faa
[^] # Re: Alternatives gratuite et moderne
Posté par steph1978 . Évalué à 2.
Framapic, coupé ?
Je vois qu'ils ont diminué la rétention, c'est lié à un incident ?
[^] # Re: Alternatives gratuite et moderne
Posté par nokomprendo (site web personnel) . Évalué à 2.
en gratuit:
- bitbucket = limité à 5 membres sur l'ensemble des dépôts privés
- framagit = limité à 42 dépôts (et c'est dommage car l'esprit git, c'est plutôt de faire plein de petits dépôts qui peuvent se combiner)
donc gitlab…
# Annonce officielle
Posté par CrEv (site web personnel) . Évalué à 4.
https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/
# Go et import path
Posté par wilk . Évalué à 2.
Bon, en Go j'ai tous mes imports avec github en dur, ça va pas faire très propre. Vivement que le projet de packages cache-proxisés aboutisse pour se libérer de mshub https://github.com/gomods/athens
Ha zut, c'est l'équipe de MS qui est là dessus aussi ! hahaha ! on est bien tien…
Allez, ne soyons pas si pessimistes et apprécions le choix fait il n'y a pas si longtemps d'utiliser des gestionnaires de version décentralisés.
[^] # Re: Go et import path
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4.
Non mais ils ont pas réglé ça chez Go encore? ça avait déjà été le gros bazar avec la fermeture de code.google.com, et ils ont recommencé avec Github ?!
Je suis déçu…
[^] # Re: Go et import path
Posté par CrEv (site web personnel) . Évalué à 2.
Quoi ? Github est fermé ?
[^] # Re: Go et import path
Posté par steph1978 . Évalué à 1.
Pour ceux qui ne veulent pas être sous la coupe de micosotf, oui.
[^] # Re: Go et import path
Posté par wilk . Évalué à 3.
"chez Go" "ils" ont toujours laissé le libre choix d'utiliser une url (à soit) indépendante du dépôt.
C'est assez paradoxal d'avoir laissé cette liberté à chacun plutôt que de tout centraliser et de voir que finalement tout le monde s'est recentralisé de son plein gré dans le premier truc fermé venu.
[^] # Re: Go et import path
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5.
Le système de build du compilateur Go lui même dépendait à l'époque de plein de trucs téléchargés depuis code.google.com. Depuis que cette plateforme est fermée, c'est impossible de compiler les vieilles versions de Go (j'ai essayé avec la 1.3) à partir des sources d'époque (je ne sais pas s'il existe des sources modifiées pour pointer sur un dépôt toujours en ligne).
# Clippy !
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
(ou Clone Wars « je suis ton père » ?)
[^] # Re: Clippy !
Posté par Faya . Évalué à 10.
https://twitter.com/AndyFitz/status/1003450513789108225
# BSOD
Posté par Ontologia (site web personnel) . Évalué à 10.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Pourquoi s’en inquiéter ?
Posté par s[e]th & h[o]lth (site web personnel) . Évalué à 5.
Parce que lorsque tu mets 7,5 milliards sur la table, c’est que tu as une idée derrière la tête…
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Albert_ . Évalué à 2. Dernière modification le 05 juin 2018 à 09:37.
Si tu associes cela avec l'achat Linkedin, tu t’aperçois que Microsoft a une visibilité sur le profile professionnel des jeunes (et moins jeunes) personnes dans le milieu de la technologie incomparable et la on voit tout l’intérêt de l'achat, faire un brain drain des jeunes talents ou assécher le vivier des développeurs opensource (voir les deux).
Après naturellement, il y a tout l'aspect possible d'analyse des tendances technologiques bien avant tout le monde (l’échantillon est "assez conséquent" avec github) etc.
Enfin il y a tellement de façon d'utiliser github et ses données tout en restant dans la légalité et en continuant leur operation de com "on est devenu gentil" que je ne vois pas pourquoi MS risquerait de faire des trucs illégales ou impopulaire. N'oublions pas que les dirigeants de MS sont des spécialistes pour dévoyer le système (c.f. la "normalisation" iso de leur format de m….), associes a cela ils ont suffisamment de sycophante pour faire leur travail de lobby et de PR.
Alors maintenant ils ont peut-être change mais j'ai comme un doute (j’attends encore la suite office sous linux, pas pour moi mais je connais suffisamment de personne qui utilise cela comme prétexte pour ne pas avoir une installation globale de linux en entreprise.)
[^] # Re: Pourquoi s’en inquiéter ?
Posté par oinkoink_daotter . Évalué à 2.
Euh … pour en faire quoi, précisément ?
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Albert_ . Évalué à 1.
Je sais pas ne pas refaire la même bêtise qu'avec XP et avoir un OS en développement et donc recruter les personnes les plus compétentes possible.
Une suggestion parmi d'autre
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Il y a une "guerre" entre les GAFAM et autres grosses boites, pour avoir les meilleurs développeurs. Celui qui a les meilleurs développeurs (et manageur aussi), a de plus fortes chances de croitre. Tu n'as pas de bons produits sans bons développeurs. Or les très bons, voir bons développeurs, ne courent pas les rues.
Aussi, si tu as accès à une base de données contenant des milliers de profils de développeurs, (et surtout la possibilité d'interroger cette base de donnée plus finement que tu ne peux le faire au travers d'une interface web publique), tu as plus de chances de trouver les perles rares, donc de les débaucher.
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Albert_ . Évalué à 1.
C'est vrai que j'ai parle de opensource quand j'aurai probablement du dire: les concurrents (au sens general).
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Jiel (site web personnel) . Évalué à 5.
Et pas seulement. Tu as aussi accès aux premiers échanges entre les recruteurs et les candidats, tu peux donc savoir comment tes concurrents s'y prennent pour débaucher des gens. Tu peux aussi, de manière peu éthique mais peu détectacle, faire que les meilleurs profils sont visibles par ton recrutement avant d'être visible par les concurrents.
[^] # Re: Pourquoi s’en inquiéter ?
Posté par pasBill pasGates . Évalué à 2.
8 milliards / 10'000 devs & managers (aller, ca doit bien être tous les devs-mgrs engagé par un des GAFAM pendant 5 ans) = $800'000 par dev
On va dire que c'est super cher payé… :)
Le problème n'a jamais été de trouver les candidats solides dans la masse des CVs, le problème c'est de leur faire accepter de quitter leur job existant pour rejoindre une nouvelle boite. Github n'aide à rien de ce côté là.
Je te parie que cela n'est même pas entré dans la tête des gens qui ont décidé d'acheter Github. Les raisons sont clairement liées aux possibilités de créer un workflow aisé avec les services de cloud et augmenter la valeur de LinkedIn pour les gens qui l'utilisent (pouvoir lier son compte github et LinkedIn pour rendre son profile plus attractif, notamment pour les gens ayant peu d'expérience).
[^] # Re: Pourquoi s’en inquiéter ?
Posté par gnumdk (site web personnel) . Évalué à 5.
Vu l'API de GitHub, y'avait pas besoin de les racheter pour faire ça :p
[^] # Re: Pourquoi s’en inquiéter ?
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Dans le message auquel je répondais, ça parlait du rachat de LinkedIn, pas de github ;-)
# Pendant ce temps, chez GitLab…
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Pendant ce temps, GitLab offre les éléments avancés de l'instance gitlab.com aux projets open-source et aux étudiants.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pendant ce temps, chez GitLab…
Posté par voxdemonix . Évalué à 4. Dernière modification le 05 juin 2018 à 19:48.
LE lien intéressant dedans : les graphiques
Par contre l'application android pour gitlab (labcoat) est moins stylée/efficace qu'octodroid.
[^] # Re: Pendant ce temps, chez GitLab…
Posté par Albert_ . Évalué à 2.
Prochaine annonce: Apple va racheter Gitlab.
[^] # Re: Pendant ce temps, chez GitLab…
Posté par pasBill pasGates . Évalué à 1.
Apple n'a rien à gagner avec ça, Amazon et Google par contre…
[^] # Re: Pendant ce temps, chez GitLab…
Posté par Albert_ . Évalué à -3.
Ah je ne savais pas que Apple ne développait pas de logiciels et n'avais aucun développeurs. Intéressant.
Ah mais c'est pas ca que tu veux dire, tu veux probablement dire que Apple serait super content de mettre en commun ses codes avec Microsofts ou Facebook.
[^] # Re: Pendant ce temps, chez GitLab…
Posté par pasBill pasGates . Évalué à 5.
Mais cela n'a rien, mais alors rien, à voir…
Ce n'est pas parce que tu développes des logiciels que cela a un sens, cela a un sens si il y a un business model te permettant de faire assez d'argent pour justifier le prix d'achat de la boite.
Et Apple n'a pas un business model qui permettrait de justifier le prix de Git(Lab|Hub) là ou les clouds providers en ont un très évident : le deploiement de ces softs sur des serveurs soit pour production soit pour test, serveurs que les gens paient.
# Dans la mouvance Auto-herbergement
Posté par Kwiknclean . Évalué à 4.
J'utilise Gogs que je fais tourner dans une petite Jail (évidemment ça tourne également dans un conteneur LxC, Ou Docker)
30 secondes pour l'installation, temps de téléchargement compris, ensuite c'est du Go donc une commande à lancer.
C'est hébergé sur une machine qui date à peu prés de l'époque avant l'ADSL et ça reste malgré tout super réactif à l'usage (vraiment bien plus vite que Github pour la partie http)
Pour un projet perso, ou pour qui veut être sur de garder la main sur l'infra, à la maison c'est idéal.
Ca doit évidemment pouvoir se déployer dans le Cloud Azur :-)
[^] # Re: Dans la mouvance Auto-herbergement
Posté par scls19fr (site web personnel) . Évalué à 1. Dernière modification le 06 juin 2018 à 21:14.
De mon côté j'utilise parfois Gitea pour quelques projets auto hébergés en local.
C'est un fork de Gogs
J'en suis très satisfait, je le fais tourner grâce à Docker sur une machine qui a une dizaine d'année sans soucis.
Les liens
https://github.com/gogs/gogs/graphs/contributors
https://github.com/go-gitea/gitea/graphs/contributors
donnent une petite idée de la différence de gestion de ces 2 forks…
# Mercurial
Posté par wilk . Évalué à -1.
Ce serait sympa que facetruc rachète gitlab, juste le temps de faire passer tout le monde sur mercurial.
[^] # Re: Mercurial
Posté par David Demelier (site web personnel) . Évalué à -2.
Il restera toujours bitbucket, mais je plussoie ton idée ;)
git is great because linus did it, mercurial is better because he didn't
[^] # Re: Mercurial
Posté par Albert_ . Évalué à 5.
Euh … non merci, au pire je repasse a git + gitolite comme au bon vieux temps :)
[^] # Re: Mercurial
Posté par groumly . Évalué à 3.
Tu veux dire pour que tout le monde se mette à utiliser tous les patchs que Facebook a fait à mercurial, qu’ils utilisent en interne?
:notsureif:
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Mercurial
Posté par David Demelier (site web personnel) . Évalué à 3.
Je ne suis pas sûr de comprendre ce que tu essaies de dire, est-ce mal ? Facebook a fait (et continue) de nous faire beaucoup de contributions et nous apprécions. Ils ont écrit des extensions intéressantes (journal, amend, absorb).
Si c'est vraiment ce que je comprends de ton message, nous devrions nous méfier du noyau Linux aussi qui a eu de nombreuses contributions d'entreprises.
git is great because linus did it, mercurial is better because he didn't
# Github sur XP
Posté par rdhlnn . Évalué à 1.
Ce que nous attendions finalement avec impatience, voilà : https://github.com/martenbjork/github-xp
(Il faut passer par le Google Chrome Web Store… Ils sont facétieux les programmeurs parfois…)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.