Microsoft jedná o koupi GitHubu

Business Insider informuje (placený obsah; shrnutí na CNBC), že Microsoft v poslední době jednal o převzetí startupu GitHub – stejnojmenná služba je nejrozšířenější hosting (open-source) softwarových projektů.

3.6.2018 22:55 | Fluttershy, yay! | Komunita

Komentáře

[David Indra]

To bude průser.

[Love_Dali]

Fork a (nebo) se půjde jinam?

[Fluttershy, yay!]

Fork

GitHub je zčásti uzavřený software.

se půjde jinam?

Bitbucket, GitLab,…

[mirec]

Github je komerčný, takže fork neprichádza do úvahy. Ak bude kúpa úspešná utekám z githubu (asi na gitlab).

[Fluttershy, yay!]

Github je komerčný

To se se svobodným/open-source softwarem nevylučuje.

Problém je, že podstatná část je proprietární.

[Bystroushaak]

Github je komerčný, takže fork neprichádza do úvahy. Ak bude kúpa úspešná utekám z githubu (asi na gitlab).

Gitlab ani není alternativa. Síla Githubu je v jeho sociální části dané centralizací. Otázka technického hostování gitových projektů je nudná a stokrát vyřešená. Co vyřešené není ani trochu je co by nahradilo tu sociální část, která stojí za úspěchem Githubu.

[ehm]

Koukám, že jsem tě včera s tím mailing listem moc nepřesvědčil. :P

[mirec]

Bitbucket má celkom dosť používateľov ale inak je to prúser. Tiež som na githube práve preto, že sa môžem zapájať do mnohých projektov.

[Bystroushaak]

Bitbucket totiž řeší jen tu hostovací část a na sociální úplně sere. Gitlab to samé, ten ale navíc vytváří ostrovy self-hosted service, které o sobě vůbec neví.

[mirec]

Veď toto. Registrovať sa na x služieb kvôli tomu aby som opravil jeden bug, ktorý mi vadí dosť zdržiava. Tiež sociálne funkcie sú fajn, following je fajn, celkovo gitub je príjemné miesto na vývoj.

[Bystroushaak]

Hlavně spoustu malých projektů budeš těžko hledat googlem. Mě třeba bavilo prostě koukat na zajímavé lidi a co dělají za projekty. To si s Gitlabama a dalšíma self-hosted servicema už neumím představit.

[Jendа]

Já to furt nechápu. Stalkuju spolužáky, přidám si do RSS feedu https://gitlab.fit.cvut.cz/hrachja2.atom. Stalkuju Medvěda, přidám si tam http://mj.ucw.cz/gitweb/?a=opml. Zajímá mě nějaký projekt, přidám si jeho RSS. Bez nějakých posraných registrací na centralizované uzavřené služby, které skončí (Google Code) nebo je koupí Microsoft.

[kralyk z abclinuxu]

No jo, ale objevitelnost nízká až nulová (musíš např. znát magické url mj.ucw.cz, které, pravda, sice zná asi tak každý matfyzák, ale ne každý člověk je matfyzák) a třeba pull request neotevřeš. (Ačkoli je mi jasný, že ty asi radši posíláš patche v příloze mailu podepsaného PGP.)

[Jendа]

musíš např. znát magické url mj.ucw.cz

Stejně tak musím znát magické URL github.com/Bystroushaak. A těm kanálům, kterými se ke mně tato URL dostala (bylo vyplněné v profilu na AbcLinuxu, MJ ho měl v patičce mailu, viděl jsem ho s commit logu nějakého open-source projektu, někdo ho poslal na IRC, vygooglil jsem ho když jsem hledal řešení nějakého problému…), je úplně jedno, jestli je to na github.com nebo nějaké jiné doméně

a třeba pull request neotevřeš

Buď mailem „Opravil jsem XYZ, pullni si https://jenda.hrach.eu/foo/bar“ nebo má-li to bugzillu/trac, tak tam udělám issue „nefunguje XYZ, v https://jenda.hrach.eu/foo/bar větvi fixit jsem to opravil“. Jediný rozdíl je v tom, že místo kliknutí na tlačítko Fork a následně na tlačítko Pull request udělám git remote add, git push, a pastnu tu URL.

[kralyk z abclinuxu]

Stejně tak musím znát magické URL github.com/Bystroushaak. A těm kanálům, kterými se ke mně tato URL dostala (bylo vyplněné v profilu na AbcLinuxu, MJ ho měl v patičce mailu, viděl jsem ho s commit logu nějakého open-source projektu, někdo ho poslal na IRC, vygooglil jsem ho když jsem hledal řešení nějakého problému…), je úplně jedno, jestli je to na github.com nebo nějaké jiné doméně

Ok, fair enough

Buď mailem „Opravil jsem XYZ, pullni si https://jenda.hrach.eu/foo/bar“ nebo má-li to bugzillu/trac, tak tam udělám issue „nefunguje XYZ, v https://jenda.hrach.eu/foo/bar větvi fixit jsem to opravil“. Jediný rozdíl je v tom, že místo kliknutí na tlačítko Fork a následně na tlačítko Pull request udělám git remote add, git push, a pastnu tu URL.

V tom vidim nevýhody oproti pull requestu. Zaprvý musíš mít vyřešen svůj git hosting. Zadruhý ten mail je potenciálně neveřejný, ostatní lidi ho uvidí, pouze pokud má ten projekt nahozený nějaký ML archiv nebo tak něco, které navíc typicky mají dost hrozné UI. Zatřetí to UI toho pull requestu je mnohonásobně přívětivější (vlastník repo si může extra snadno na jedno kliknutí zobrazit změny, ...) a poskytuje o dost víc fíčur pro codereview - např. možnost komentovat jednotlivé řádky kódu, mít nějakou historii vývoje té změny, integrace s CI (řada projektů to má tak, že CI automaticky kontroluje pull requesty) apod.

[Michal Kubeček]

Zatřetí to UI toho pull requestu je mnohonásobně přívětivější (vlastník repo si může extra snadno na jedno kliknutí zobrazit změny, ...) a poskytuje o dost víc fíčur pro codereview - např. možnost komentovat jednotlivé řádky kódu, mít nějakou historii vývoje té změny, integrace s CI (řada projektů to má tak, že CI automaticky kontroluje pull requesty) apod.

To je otázka preferencí. Mně třeba celá tahle UI mašinerie z řady důvodů moc nevyhovuje. Ani ten nejtriviálnější fix nemůžu vzít jako fast forward, vždycky tam bude strašit merge commit. Pokud budu chtít opravit zjevný překlep v commit message, mám smůlu. Budu-li chtít udělat follow-up, můžu to udělat až po merge commitu.

Zrovna před pár dny jsem přesně tohle řešil. Dostal jsem pull request, který vypadal rozumně, ale potřeboval jsem ho aplikovat do jiné větve, přidat k němu follow-up a pak teprve udělat merge do aktivních větví (včetně té, proti které byl ten pull request). Takže jsem stejně musel udělat všechno ručně, jako kdyby ten patch přišel přes mail (jen cherry-pick místo am) a pak ten pull request formálně zamítnout (přestože jsem ho fakticky přijal).

Stejně tak mi připadá pochybený celý koncept "forků" na githubu, který mne nutí kvůli submitnutí jednoho patche vyrobit celý "fork" se všemi větvemi. V praxi to nakonec dopadne tak, že někdy na začátku vytvořím "fork", který ale ve skutečnosti vůbec neudržuju, lokálně všechno řeším na klonu původního repozitáře a teprve pro pull request pushnu jednu konkrétní branch (ale svou vlastní) do toho svého "forku" a přes UI udělám pull request.

Když se nad tím zamyslím, tak ve výsledku vlastně všechen ten komfort githubu častěji obcházím než využívám.

[kralyk z abclinuxu]

Dostal jsem pull request, který vypadal rozumně, ale potřeboval jsem ho aplikovat do jiné větve, přidat k němu follow-up a pak teprve udělat merge do aktivních větví (včetně té, proti které byl ten pull request). Takže jsem stejně musel udělat všechno ručně, jako kdyby ten patch přišel přes mail (jen cherry-pick místo am) a pak ten pull request formálně zamítnout (přestože jsem ho fakticky přijal).

U pull requestu můžeš změnit target branch. (Klik Edit a ze seznamu vybrat branch.)

Co se týče ostatního, IMHO github není moc o tom, že by abstrahoval práci s gitem jako takovým, tj. řešit ručně git přes příkazovou řádku (např.) je v pořádku. (A popravdě mně třeba to stejně vyhovuje víc než nějaké frontendy.)

Jde tam spíš o ty věci okolo, které už jsem zmiňoval já i jiní, třeba např. to, že já ten pull request můžu vidět, dají se tam vést ty diskuse atd.

Nutné merge commity jsou určité omezení, to beru jako výhradu.

Stejně tak mi připadá pochybený celý koncept "forků" na githubu, který mne nutí kvůli submitnutí jednoho patche vyrobit celý "fork" se všemi větvemi. V praxi to nakonec dopadne tak, že někdy na začátku vytvořím "fork", který ale ve skutečnosti vůbec neudržuju, lokálně všechno řeším na klonu původního repozitáře a teprve pro pull request pushnu jednu konkrétní branch (ale svou vlastní) do toho svého "forku" a přes UI udělám pull request.

Vadí to něčemu? Myslimže to je celkem standardní postup... Ten "fork" nemá znamenat, že nutně hnedka forkuješ projekt a rozjíždíš nezávislý vývoj

[Michal Kubeček]

U pull requestu můžeš změnit target branch. (Klik Edit a ze seznamu vybrat branch.)

To ne vždy řeší problém, protože by se do té cílové větve udělal merge, zatímco já potřeboval aplikovat jen ten jeden nový commit.

Vadí to něčemu? Myslimže to je celkem standardní postup... Ten "fork" nemá znamenat, že nutně hnedka forkuješ projekt a rozjíždíš nezávislý vývoj

Terminologie není nejšťastnější, ale spíš mi vadí ta koncepce. Nejsem si úplně jistý, že je opravdu nutné mít jeden remote pro upstream a druhý pro můj fork. Ono by to asi šlo i s jedním, ale to by musela být podpora pro automatickou synchronizaci s upstreamem, jinak se z toho člověk zblázní. A když už jsou dva, proč v tom svém musím nutně mít (neudržované) klony všech upstreamových větví, když je stejně vůbec nepoužívám a náhodnému kolemjdoucímu jen maskují to podstatné?

[kralyk z abclinuxu]

To ne vždy řeší problém, protože by se do té cílové větve udělal merge, zatímco já potřeboval aplikovat jen ten jeden nový commit.

Taky bych ideálně bral možnost dělat fast-forward merge, myslimže mi to trochu vadilo u gitlabu posledně. Ale popravdě mi to nepřijde jako nějak moc důležité.

Terminologie není nejšťastnější, ale spíš mi vadí ta koncepce. Nejsem si úplně jistý, že je opravdu nutné mít jeden remote pro upstream a druhý pro můj fork.

Myslim si, že hlavní důvod jsou práva. Pokud bys neměl svůj fork, kam bys pushoval změny k nahlédnutí? Musely by se třeba řešit nějaká práva na nějaké větve v upstreamu... Oproti tomu s těmi forky je to jednoduché fungující řešení.

[Michal Kubeček]

Taky bych ideálně bral možnost dělat fast-forward merge, myslimže mi to trochu vadilo u gitlabu posledně. Ale popravdě mi to nepřijde jako nějak moc důležité.

Nešlo o to, že bych trval na fast forwardu, to je opravdu spíš kosmetická drobnost. Spíš jsem měl na mysli situaci, kdy mám nějakou základní větev B, kam patří údržba "společné infrastruktury" a pak několik aktivních větví A1, A2, A3, do kterých se po změně "infrastruktury" B merguje. Přijde mi pull request se změnou "infrastruktury" proti A1, ale já to chci udělat v B, aby pak stačilo provést merge do A1, A2 i A3. Ale nemůžu udělat merge toho pull requestu do B, protože tím bych tam dostal i celou historii A1.

Mimochodem, jak jsem teď zjistil, v tom případě před týdnem to tak vlastně nebylo, tam jsem nakonec potřeboval jen trochu učesat a doplnit commit message.

Pokud bys neměl svůj fork, kam bys pushoval změny k nahlédnutí?

To úplně do detailu rozmyšlené nemám. Nakonec by mi asi stačilo, kdyby šel udělat "prázdný fork", kam bych pushoval jen své větve s mou prací.

[kralyk z abclinuxu]

Nešlo o to, že bych trval na fast forwardu, to je opravdu spíš kosmetická drobnost. Spíš jsem měl na mysli situaci, kdy mám nějakou základní větev B, kam patří údržba "společné infrastruktury" a pak několik aktivních větví A1, A2, A3, do kterých se po změně "infrastruktury" B merguje. Přijde mi pull request se změnou "infrastruktury" proti A1, ale já to chci udělat v B, aby pak stačilo provést merge do A1, A2 i A3. Ale nemůžu udělat merge toho pull requestu do B, protože tím bych tam dostal i celou historii A1.

Jo takhle. Modus operandi na GH je, že prostě požádáš toho člověka, aby tohle udělal, tj. třeba "proveď prosím rebase na větev XY a fixni typo v commit message". Požádat toho člověka o tyhle úpravy mi přijde naprosto v pořádku, třeba žádosti o squash commitů vzniklých v průběhu codereview jsou běžné. Případně pokud z nějakého důvodu to chceš opravdu udělat sám, pak ruční řešení pomocí gitu je na místě, protože už to není tak úplně jednoduchá operace a obecně ani nejde automatizovat (protože merge/rebase konflikty).

To úplně do detailu rozmyšlené nemám. Nakonec by mi asi stačilo, kdyby šel udělat "prázdný fork", kam bych pushoval jen své větve s mou prací.

Ok, "forkni jen s touhle větví" by asi byla celkem užitečná féčura...

[Bystroushaak]

V tom vidim nevýhody oproti pull requestu. Zaprvý musíš mít vyřešen svůj git hosting. Zadruhý ten mail je potenciálně neveřejný, ostatní lidi ho uvidí, pouze pokud má ten projekt nahozený nějaký ML archiv nebo tak něco, které navíc typicky mají dost hrozné UI. Zatřetí to UI toho pull requestu je mnohonásobně přívětivější (vlastník repo si může extra snadno na jedno kliknutí zobrazit změny, ...) a poskytuje o dost víc fíčur pro codereview - např. možnost komentovat jednotlivé řádky kódu, mít nějakou historii vývoje té změny, integrace s CI (řada projektů to má tak, že CI automaticky kontroluje pull requesty) apod.

Taky to není veřejná komunikace a ostatní vůbec nevidí, že se nějaká issue řeší a nemůžou se k ní ani normálně vyjádřit. To trochu řeší mail-list, ale to je samo o sobě dost dementní technologie. Ne že by web byl lepší, ale stavět cokoliv na mailem je bolest plná spam filtrů a nepodporovaných standardů, když úplně vynechám, že to by default nemá historii.

[Michal Kubeček]

Samozřejmě. To je přeci každému na první pohled jasné, že něco takového už od pohledu pro větší projekt nemůže fungovat. A už vůbec ne dlouhodobě.

(sarcasm sign)

[Bystroushaak]

Jo, u kolika tvých projektů to funguje? Protože já to zkoušel a nefungovalo to u žádného mého. Ale rád se nechám poučit co jsem dělal blbě. Četl jsem například Tvorba open source softwaru od Karla Fogela, a získal jsem pocit, že pro tenhle přístup musíš mít hodně slávy před tím, než vůbec začneš, protože jinak se prostě nikdo nezapojí.

[Michal Kubeček]

Já především nemám ambice něco rozjet ve velkém a zapojit co nejvíc lidí. Na githubu mám IIRC jen dvě vlastní věci. Jedna je tam spíš "kdyby to někoho zajímalo" (a musím říct, že zájem mne celkem překvapil, ale jestli časem budou i nějaké zásadní příspěvky zvenčí, to se teprve uvidí), druhá jen trackuje postup dlouhodobějšího projektu, který se ale diskutoval a bude diskutovat v příslušném mailing listu.

Tady jsem jen reagoval na komentář, který vyzníval, jako by vývoj založený na mailing listu byl naprosto neudržitelný a nemohl fungovat už z principu. Přitom ze zkušenosti vím, že nejen může, ale dokonce tak může fungovat i lépe než u mnohých projektů, které mají hyper cool workflow a nejmodernější nástroje. Ale stejně tak nemusí. Ono je to nakonec vždycky především o lidech a jejich přístupu, nástroje jsou až druhotné.

[Bystroushaak]

Tady jsem jen reagoval na komentář, který vyzníval, jako by vývoj založený na mailing listu byl naprosto neudržitelný a nemohl fungovat už z principu. Přitom ze zkušenosti vím, že nejen může, ale dokonce tak může fungovat i lépe než u mnohých projektů, které mají hyper cool workflow a nejmodernější nástroje. Ale stejně tak nemusí. Ono je to nakonec vždycky především o lidech a jejich přístupu, nástroje jsou až druhotné.

Jo, to nepopírám. Ale třeba můj use-case je, že tam mám přes 60 projektů menšího rozsahu. Něco z toho jsou blbosti, něco relativně jednoduché knihovny, jako bottle-rest, které jen přidávají nějakou funkcionalitu. Představa, že bych měl instalovat a spravovat a starat se o mailovou konferenci mě netěší, a představa, že bych měl spravovat a starat se o 60 mailových konferencí už vůbec. Nehledě na to, že lidi z mé zkušenosti nepíšou na osobních webech ani do diskuzí, kde se nemusí registrovat. Na mail-list napíše fakt jen dedikované jádro, které u těhle malých projektů neexistuje.

S mail-listama mám taky zkušenosti, většinou se ale spíš snažím najít NNTP odběr. Beru tahle Self, Smalltalk a Pharo konference. Nemůžu tvrdit, že by mi to vyhovovalo. Co mi přijde hrozné je třeba lag, který to má (běžné je půl hodiny+). Pak taky (ne)podpora hlavičky Reply-To, kterou každý klient podporuje jinak a láme to threadování.

Osobně chápu nebezpečí centralizace, ale nevidím důvod se mu vyhýbat jen tak z principu. Ostatně abclinuxu je docela pěknou ukázkou jaké to má výhody. Víc přečtení mých blogů, víc komentářů, víc feedbacku. Přitom taky málokdo řeší, jak odsud dostat své blogy jinam, kdyby ho náhodou koupil microsoft (:D). Já to například vyřešené mám.

[Michal Kubeček]

Především si nemyslím, že existuje nějaké univerzálně nejlepší řešení. Někomu může nejvíc vyhovovat mailing list, někomu na všechno github/gitlab, někdo sice poběží na githubu, ale zároveň bude používat bugzillu… Co jsem chtěl říct, je, že si nemyslím, že kterýkoli z těch přístupů je a priori dobrý nebo špatný. A že pro každý by se daly najít příklady, kde to funguje i kde to nefunguje.

Naprosto souhlasím, že pro malý projekt, kde člověk chce mít základní servis s minimem úsilí, je github (nebo třeba gitlab) naprosto ideální a rozhodně nemám nikomu za zlé, že po něm sáhne.

[kralyk z abclinuxu]

Tady jsem jen reagoval na komentář, který vyzníval, jako by vývoj založený na mailing listu byl naprosto neudržitelný a nemohl fungovat už z principu. Přitom ze zkušenosti vím, že nejen může, ale dokonce tak může fungovat i lépe než u mnohých projektů, které mají hyper cool workflow a nejmodernější nástroje. Ale stejně tak nemusí. Ono je to nakonec vždycky především o lidech a jejich přístupu, nástroje jsou až druhotné.

Taky mam zkušenost s projekty s workflow nad mailing listem, kde to fungovalo lépe než u některých projektů na Githubu (apod.).

Nicméně když bych třeba dneska chtěl publikovat nový FOSS projekt, jak se budu rozhodovat? Budu vědět, že nastavit nějaký ML + hosting + bug tracker bude spousta práce, zatímco na Githubu (příp. Gitlabu) udělám git push a mám v zásadě všechno, co budu potřebovat a s řádově větší šancí, že někdo nahlásí chybu nebo pošle patch...

[Gilhad]

Mam to taky tak, githubove projekty se ke me dostavaji zcele jinymi cestami, nez ze bych je nasel na githubu.

Chystal jsem se tam ted dat nejake svoje veci, co jsou ve stavu, ze by staly za publikaci, ale zatim jsem jen otestoval, jak zaridit, aby hlavni server byl u me a dalo se to s githubovou verzi nejak rozumne synghronizovat. Takze tech par pokusu, co jsem tam dal (jako na secondary server) jsem zase stahnul a pockam si, kam se komunita hne.

Mezitim se aspon dokopu k tomu si udelat vlastni "frontend git server", na ktery budu odkazovat zajemce o svuj kod a dopiluju pri tom workflow, aby to nedrhlo. Zaklad je ale samozrejme porad na mojem internim serveru, tohle vsechno jsou veci okolo.

[Jendа]

Ale OK, chápu problém, že třeba nejde snadno udělat reverzní lookup „do jakých všech projektů ten člověk přispěl“. Nemohly by tohle fixnout nezávislé agregátory gitového provozu?

[Bystroushaak]

Jako, já když tu říkám, že Github měl svoje výhody, tak pořád platí, že nezávislé agregátory / federace / distribuované systém bych viděl o hodně radši.

[Jendа]

Registrovať sa na x služieb kvôli tomu aby som opravil jeden bug, ktorý mi vadí dosť zdržiava.

Tohle se ale neřeší centralizovanou službou, ale OpenID. Nevýhoda centralizované služby je, že pokud je z jakéhokoli důvodu pro konkrétního jedince nedostupná (žije ve státě, který mají USA na blacklistu, v ToS jsou nepřijatelné věci, prodává data ďáblu…), tak jaksi nemůže nic.

[kralyk z abclinuxu]

Tohle se ale neřeší centralizovanou službou, ale OpenID.

Tohle mi přijde jako zavádějící tvrzení, skoro spíš klamavé.

OpenID je jedna z technologií v kategorii "úspěšně by to řešilo problémy, kdyby to lidi používali". Aktuální situace je taková, že centralizovaná služba ten problém řeší, zatímco OpenID ho neřeší, protože s OpenID účtem se skoro nikam nepřihlásim.

V hypotetickém světě, kde by OpenID byl rozšířený a lidi ho používali, by ty problémy řešil.

Na tohle narážim v diskusích tohohle typu už poněkolikáté: Zastánce decentralizovaných řešení se tváří, jako kdybychom byli v tom hypotetickém světě, kde člověk může toho benefitu decentralizované služby X využít. Přitom ale reálně tu službu k tomu účelu, který bych potřeboval, využít nemůžu, protože prostě jsme ve světě reálném, což je nepříjemné, ale co se dá dělat.

Tohle je diametrální rozdíl od klasického FOSS softwaru, jako třeba nějaká utilita pro nějaký účel, která nemá jako podmínku své užitečnosti bandwagon effect milionů lidí. Typicky stačí pár nadšenců a ten software je užitečný. Linux desktop používá kolik % lidí? Málo, ale to mi nijak nebrání mít obrovský užitek z Linux desktopu. Tohle ale není případ technologie jako OpenID nebo decentralizované sociální sítě. Jejich zastánci se ale tváří, jako kdyby to bylo to samé. Proč?

[ehm]

Jaký je rozdíl zaregistrovat se na nějaké Abclinuxu, nebo si pořídit (i třeba kvůli jediné službě) OpenID? Skoro žádný. Takže tím padá argument, proč při stavění nové služby OpenID nepoužít.

[Bystroushaak]

OpenID ti pořád neřeší discoverabilitu.

[kralyk z abclinuxu]

Jaký je rozdíl zaregistrovat se na nějaké Abclinuxu, nebo si pořídit (i třeba kvůli jediné službě) OpenID? Skoro žádný. Takže tím padá argument, proč při stavění nové služby OpenID nepoužít.

ROFL. To je opravdu skvělé že "padá argument, proč při stavění nové služby OpenID nepoužít". Q: K čemu mi to konkrétně v praxi je? A: Vůbec k ničemu. Stále platí, že se s OpenID nikam nepřihlásím a argument může padat třeba do horoucích pekel a nic se na tom nezmění.

[ehm]

i.e. pokud teď lidi řeší, kam migrovat, a řeší to i tady na jednom fóru, můžou se pro případ self-hosted řešení domluvit na používání OpenID a tím už vznikne nějaká síť, kde se lze pohybovat bez potřeby dalších registrací.

[kralyk z abclinuxu]

Ok, to už zní rozumněji. Já sám nevím o nic lépe, jak toho dosáhnout, aby decentralizovaná síť byla skutečně použitelnou, IMHO ale ten OpenID je víceméně technický detail, hlavní je to magické "aby se lidi domluvili". Tady by možná nebylo špatné začít věcmi jako je ekonomie a teorie her, ale těžko říct...

[Jendа]

Tohle mi přijde jako zavádějící tvrzení, skoro spíš klamavé.

Není, jenom jsi ho špatně pochopil. To neznamenalo, že ty hned teď můžeš začít používat OpenID, ale že technicky dobrý způsob, jak to vyřešit, je OpenID.

Aktuální situace je taková, že centralizovaná služba ten problém řeší

Zajímavé, mně přišlo, že takhle diskuze je o tom, že centralizovaná služba právě problém řešit přestala (tím že ji někdo koupil a stala se pro lidi nepřijatelnou).

[kralyk z abclinuxu]

Není, jenom jsi ho špatně pochopil. To neznamenalo, že ty hned teď můžeš začít používat OpenID, ale že technicky dobrý způsob, jak to vyřešit, je OpenID.

Já to chápu a nesouhlasím s tím, resp. hlavně s tím, že má smysl posuzovat pouze ten ryze technický / implementační aspekt, jestliže použitelnost toho pojektu je tak hodně závislá na společenských aspektech. Z toho pohledu je projekt OpenID nezvládnutý, protože to, že autoři ten společenský rozměr / badwagon efekt / teorii her neřešili nebo řešili neúspěšně má stejný dopad, jako kdyby udělali nějakou zásadní implementační / technickou chybu.

Tudíž OpenID, alespoň v aktuální podobě, není dobrým řešením toho problému.

Zajímavé, mně přišlo, že takhle diskuze je o tom, že centralizovaná služba právě problém řešit přestala (tím že ji někdo koupil a stala se pro lidi nepřijatelnou).

No, to IMHO zatím úplně nevíme, to se uvidí, ale zatím mi přijde, že to tak spíš nevypadá.

[Jendа]

Tudíž OpenID, alespoň v aktuální podobě, není dobrým řešením toho problému.

Furt se nechápeme. Řešení 1: založíš novou centralizovanou službu a musíš všechny přesvědčit, aby ji začali používat. Řešení 2: použiješ OpenID a musíš všechny přesvědčit, aby to začali používat.

[kralyk z abclinuxu]

Hm? Jestli jsem to dobře pochopil, tak jsi chtěl říct, že ten problém řeší řešení 2. Já jsem nesouhlasil, myslim si, že ho spíš řeší řešení 1. V čem se nechápeme?

[Jendа]

Ty tvrdíš, že 2 není řešení, protože vyžaduje přesvědčit všechny, aby používali OpenID. Já tvrdím, že v tom případě není řešení ani 1, protože musíš přesvědčit všechny, aby používali tu centralizovanou službu.

[kralyk z abclinuxu]

Rozumim, ale jde o to, že to není to samé. Když tvoříš nějakou službu, jsi schopen víceméně od chvíle spuštění poskytnout uživatelům nějaký benefit (pokud ta služba nějaký benefit poskytuje, což předpokládám, že ano). Čiliže za přidání se je čeká nějaký zisk v nějaké formě. Tohle u toho OpenID neplatí nebo problematicky. Benefit uživatelům to poskytne až ve chvíli, kdy nejen ty nabízíš OpenID login, ale kdy ho nabízí i dostatečné množství dalších vendorů. Takže na začátku nemůžeš poskytnout nic uživatelům, musíš nejprve jít za poskytovateli služeb. Z jejich pohledu to je bohužel podobné - je pravděpodobné, že se přidají až když se přidá dost ostatních. Můžeš je motivovat možností, že jim pak přijde víc uživatelů, ale to je opět benefit, který je až někdy v budoucnu pokud na to naskočí dost dalších vendorů a lidí. Taky to pro ně znamená minimálně potenciálně nějaké technické obtíže navíc, můžou mít pocit, že nemají pod kontrolou, kdo se jim přihlašuje do systému etc.

[Jendа]

Když se dá přes OpenID přihlásit jen do pár projektů na světě, tak je to stejné, jako když mám novou centralizovanou službu, kde je jen pár projektů…

Takže na začátku nemůžeš poskytnout nic uživatelům, musíš nejprve jít za poskytovateli služeb. Z jejich pohledu to je bohužel podobné - je pravděpodobné, že se přidají až když se přidá dost ostatních. Můžeš je motivovat možností, že jim pak přijde víc uživatelů, ale to je opět benefit, který je až někdy v budoucnu pokud na to naskočí dost dalších vendorů a lidí. [...] můžou mít pocit, že nemají pod kontrolou, kdo se jim přihlašuje do systému etc.

Tohle všechno platí i pro centralizované služby.

[kralyk z abclinuxu]

Když se dá přes OpenID přihlásit jen do pár projektů na světě, tak je to stejné, jako když mám novou centralizovanou službu, kde je jen pár projektů…

Nemyslim si to. IMHO ten OpenID má tu pozici těžší, z několika důvodů:

Musí se prosazovat ve dvou rozměrech - mezi vendory služeb a mezi uživateli. Např. na případu StackExchange, kde podpora OpenID bude teď končit mi přijde, že rozšíření mezi uživateli nestačí - ti uživatelé přestanou používat svůj OpenID účet když vidí, že jim víceméně není k ničemu jinému než k přístupu k SE. (Takhle přesně jsem to měl taky.)

Adopce OpenID, zejména na straně poskytovatele služby, vyžaduje IMHO o dost vyšší počáteční investici a přináší vyšší rizika než přidání se na centralizovanou službu. Ačkoli s těmi riziky je to samozřejmě sporné - třeba u Facebooku vidím to riziko určitě vyšší - nicméně z toho herně-teoretického pohledu je potřeba brát v úvahu hlavně riziko vnímané uživatelem spíše než skutečné (čti: lidi mají tendenci podceňovat riziko Facebooku a přeceňovat riziko něčeho, co vypadá "moc technicky").

Co se Githubu týče, vidím přínos i kdybych byl první a jediný uživatel - stále je to extra snadný způsob jak vystavit projekt včetně hezkého procházení prostoru i času projektu, Markdown, wiki pages atd., issues, které nejsou co do bariéry vstupu horší než jinde, ale nemusim se starat o hosting, etc. Navíc v době, kdy Github vznikl a rostl, ty self-hosted alternativy moc neexistovaly.

Co se týče třeba sociálních sítí, tak tam souhlasim, že ten benefit je taky spíš až s tou adopcí. U jiných služeb záleží - u některých bandwagon nepotřebuješ, třeba rajce.idnes.cz. Pak jsou třeba služby jako Strava/Endomondo/et al., které jsou na tom IMHO podobně jako Github, čili jiní uživatelé jsou benefit, ale užitek máš i bez nich. Nicméně i v případě, kdy závislost na tom bandwagon efektu je stejná, stále IMHO má decentralizovaná síť nevýhodu v o něco vyšší technické náročnosti, a to i pro běžného uživatele (třeba v Disapoře volba podu, kde je potřeba aspoň rámcově vědět co je pod, jaké jsou pody a jaká je implikace volby (bude mnou vybraný pod naživu ještě za 5 let?)).

Jako určitou nevýhoda těch decentralizovaných řešení vidim taky to, že jsou reaktivní spíš než proaktivní, tj. Gitlab je reakce na Gihub, Diaspora na Facebook/Twitter, atd., přijde mi, že to trochu stěžuje pozici, protože se musejí přizpůsobovat a překecávat stávající 'spokojené' uživatele...

Jinak obecně já si tady konkrétně v tomhle vlákně stěžuju na nevýhody OpenID, ale přijde mi jako špatné už to, že tyhle projekty ty herně-teoretické aspekty neřeší nebo málo. Teď jsem zběžně koukl na tu Diasporu, kterou jsem před několika lety zkoušel používat. Hodnotím kladně přidání propisování na FB a Twitter. Pokud by to bylo dostatečně hladce propojitelné/integrovatelné, to by mohla být zajímavá možnost. No ale kouknul jsem se, jestli nemají něco na to téma, které tady řeším, a našel jsem tuhle wiki stránku, kde ale bohužel sekce "Appealing to End Users" dost zeje prázdnotou a doporučení "Like us on Facebook" vnímám jako dosti špatný vtípek.

Přitom bych očekával, že nějaká herně-teoretická analýza nebo alespoň nějaké zamyšlení na to téma by měly mít vysokou prioritu, IMHO by něco takového mělo nastat ještě než člověk začně psát nějaký kód. Ono by to totiž taky asi mělo i technické implikace.

Ale jinak jasně, je snadný tohle vyžadovat po někom jiným a já jim na druhou stranu rozumim, že raději programují, to já koneckonců taky...

[elenril]

Tak aspon že ne google.

[pc2005]

Ten už repo web měl a zrušil ho .

[ehm]

Představte si ten paradox, kdy by Linux byl vyvíjen na službě Microsoftu. Když jsem tu před časem někde psal, že se mi nelíbí, jak se vývoj FOSS kvůli Githubu centralizuje, netušil jsem, že je potenciální problém za dveřmi tak brzo.

[Michal Kubeček]

Repozitář, na který odkazujete, je jen mirror, primární (pokud nepočítáme Linusův notebook) je tenhle.

[ehm]

To jsem nevěděl. Díky.

[sonicpp]

Tak jako jsem opustil po koupi LinkedIn, tak opustím i GitHub (jen nevím jestli přejdu na BitButcket, GitLab nebo něco jiného)

[qwertz]

skončí to jak sourceforge

[tutanchamon]

a ako skoncilo sourceforge?

[mirec]

Z kedysi najpoužívanejšieho hostingu pre projekty sa stala reklamná plocha s tlačidlom download. Github prišiel v správnom čase so správnym projektom (jednoduchá možnosť zapojiť sa do projektu bez toho aby som musel žiadať o povolenie od autora, možnsť okamžite urobiť fork, možnosť pozrieť si forky ostatných používateľov ak je projekt mŕtvy a zapojiť sa do najaktívnejšieho ...).

[pc2005]

sourceforge tam přibaloval nějaký adware jestli si dobře pamatuju ne?

[Fluttershy, yay!]

Od té doby se změnil provozovatel.

[pc2005]

Jo ale to ten portál IMO zabilo.

[R]

Takze rychlo vymazat vsetky repozitare a zrusit konto?

[Peter Golis]

Zmigruj na Slashdot. Tam ti to budú spravovať bez teba, a pribalia do toho aj nejaké reklamné programy.

[Grunt]

Embrace, extend, and extinguish? Microsoft se očividně zas snaží…

[MP]

Co ma EEE spolecneho s Githubem? Resp., on je na Githubu pouze vyvoj pro Linux?

[Kate]

No, přinejmenším bych se bála o osud editoru Atom, který vyvíjí GitHub a přímo konkuruje Visual Studiu Code.

[pc2005]

Já bych se bál o všechny hackovací softy, obzvlášť ty pro hackování microsoft produktů.

[Grunt]

Nic. Oni to totiž jen koupí (jestli to vůbec koupí) a následně znefunkční, nic nebudou rozšiřovat.

[Fluttershy, yay!]

ACKSHYUALLY, hodila by se jim integrace s Azure, aby měli pod kontrolou celý řetězec ve vývoji.

[Kate]

Přesně, Github se Microsoftu opravdu hodí. Uzavírat to o moc víc nejde, kompletně zpoplatnit taky ne (tím by si zabili produkt).

Rozhodně by Github pod taktovkou Microsoftu nemusel dopadnout tak špatně jako dopadl po změně majitele Sourceforge.

[Fluttershy, yay!]

Třeba integrace s LinkedIn by mohla být dost otravná. Přispěješ do projektu s komerční podporou a zasypou tě nabídkami práce ve firmě, která tu podporu poskytuje.

Taky je otázka, jak by reagovali na kontroverzní projekty, jak by se změnily ToS,…

[Max]

Tak tak, začnou to postupně propojovat se svými technologiemi. Takže Azure a postupně se bez windows live účtu na github noví uživatelé nepřihlásí, odstraní barevná témata a přejdou na ten jejich čistý vzhled, nasadí 10px padding atd. atd.
Černějších scénářů může být více :).
Zdar Max

[Grunt]

Jakože valnou většinu open-source světa by měl uložené u sebe na svých serverech Microsoft? Teda jako horory jsem četl všelijaké, ale takový bych nevymyslel ani kdybych chtěl.

[Bystroushaak]

Pokud to fakt koupí MS, tak se dá čekat masivní odliv jinam. Otázkou je kam. Já bych rád viděl nějaké distribuované řešení;

Něco co bych si nahodil na server a ono si to povídalo s ostatními servery a vytvářelo zdání celého velkého „sociálního prostoru“, kde jsou přístupné všechny projekty v síti, komentáře, issue, wiki stránky a tak podobně, i když reálně u sebe hostuji jen ty svoje. Neexistuje už náhodou něco podobného? Něco co by fungovalo podobně jako Mastodon, nebo Scuttlebutt.

Osobně vidím výhodu Githubu právě v té sociální části. Ostatně nebýt GH tak jsem se asi nikdy tolik nezapojil do opensource projektů a když už, tak asi jen do těch větších. Díky GH čas od času posílám commity i do těch úplně mrňavých, čistě protože se dají jednoduše najít a nebýt githubu, tak bych se o nich ani nedozvěděl.

Taky se mi líbí ta filosofie „code first“ a že člověk u menších projektů nemusí vymýšlet žádnou prezentaci - samotný kód je tou prezentací. Vzpomínám si ještě na doby, kdy si člověk musel dělat pro svoje projekty vlastní stránky, což i když už náhodou udělal, tak zabilo objevitelnost (než to zaindexuje google a na jakou pozici to asi tak dá) a u ostatních lidí ochotu zapojit se (nebudou vymýšlet jak kód stáhnout, provést patche a dát mi o nich vědět).

[kralyk z abclinuxu]

Pokud to fakt koupí MS, tak se dá čekat masivní odliv jinam.

To bych neřekl. Nějaký odliv možná jo, ale divil bych se, kdyby větší než dost zanedbatelný. Přijde mi to podobné někdejším výhružkám "Odstěhuju se do Kanady, když vyhraje Trump".

Otázkou je kam. Já bych rád viděl nějaké distribuované řešení.

To já taky, problém je, že tyhle řešení prostě nemají popularitu. To je problém mnohem důležitější než veškeré technické detaily. A tenhle problém, přijde mi, lidi buď vůbec neřeší a zabývají se těmi technickými detaily, anebo by ho i řešili, ale nevědí, co s ním (to jsem třeba já).

[Bystroushaak]

To bych neřekl. Nějaký odliv možná jo, ale divil bych se, kdyby větší než dost zanedbatelný. Přijde mi to podobné někdejším výhružkám "Odstěhuju se do Kanady, když vyhraje Trump".

Tak já nevím jaké z toho máš pocity ty, ale výjimkou VS code mi přijde prakticky veškerý SW od MS totálně na kokot. Vzhledem k tomu, co udělal ostatním sežraným službám si troufám pochybovat, že by GH zůstal stejně použitelným, i kdybych náhodou chtěl hostovat zrovna u MS z filosoficko-morálních důvodů.

To já taky, problém je, že tyhle řešení prostě nemají popularitu.

A ty o nějakém víš? Já nic nenašel.

[Grunt]

Tak já nevím jaké z toho máš pocity ty, ale výjimkou VS code mi přijde prakticky veškerý SW od MS totálně na kokot. Vzhledem k tomu, co udělal ostatním sežraným službám si troufám pochybovat, že by GH zůstal stejně použitelným, i kdybych náhodou chtěl hostovat zrovna u MS z filosoficko-morálních důvodů.

Tohle je velmi dobře známá a popsaná firemní strategie Microsoftu. Resp. chování vzhledem ke konkurenci. Já bych zatím s emocema brzdil. Jestli jsem to dobře pochopil, je to jen něco ve smyslu jedna paní povádala…

[k3dAR]

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

[Grunt]

Ok. Teď je čas začít panikařit.

[Bystroushaak]

https://news.microsoft.com/2018/06/04/microsoft-to-acquire-github-for-7-5-billion/

Ok, takže kam?

[kralyk z abclinuxu]

Viděl bych to na -41, alespoň do doby, než opadne panika.

[kralyk z abclinuxu]

GitHub will retain its developer-first ethos and will operate independently to provide an open platform for all developers in all industries. Developers will continue to be able to use the programming languages, tools and operating systems of their choice for their projects — and will still be able to deploy their code to any operating system, any cloud and any device.

To říkám, že si nic nedovolí...

Alespoň prozatím

[Grunt]

Si povíme. Jak Microsoft operuje vím velice dobře.

[Bystroushaak]

To říkám, že si nic nedovolí...

Alespoň prozatím

No nevím, věřit Microsoftu? To bych asi víc věřil ďáblu.

[kralyk z abclinuxu]

Tak jasně, ale nepřijde mi, že by se to dramaticky lišilo od "věřit Gihubu". Github není víc důvěryhodný než MS už jenom z toho induktivního důvodu, že je ochoten prodat tu službu MS.

[Bystroushaak]

Tak jasně, ale nepřijde mi, že by se to dramaticky lišilo od "věřit Gihubu". Github není víc důvěryhodný než MS už jenom z toho induktivního důvodu, že je ochoten prodat tu službu MS.

Jde tu taky o historii. A ta říká, že MS nemáš věřit ničemu. GH doteď historický záznam špatný neměl.

[pc2005]

Jde tu taky o historii. A ta říká, že MS nemáš věřit ničemu.

+1

[kralyk z abclinuxu]

Nemyslim si, že by to v týhle situaci hrálo až takovou roli. Github sice neměl zářezy, jaký má za sebou MS, ale imho nebylo ani moc důvodů mu nějak extra věřit.

Ty důvody pro hledání alternativy chápu a souhlasim, ale myslim si, že byly v zásadě stejně platné před akvizicí MS jako teď.

[Jendа]

To říkám, že si nic nedovolí...

Schválně zkus najít podobné vyjádření když koupili Skype a Nokii.

OTOH LinkedIn je pořád úplně stejně nakokot, možná tam už nebylo co zničit

[Michal Kubeček]

Skype byl koupen v roce 2011. Nokia (tedy její mobilní divize) sice až 2014, ale od roku 2011 už fungovalo "partnerství" a v tom roce 2014 už to byla spíš rána z milosti. Posun v přístupu MS oproti Ballmerově éře je více než zjevný. Samozřejmě je to z velké části reakce na změněnou situaci a nikde není psáno, že svůj přístup zase nezmění, ale nečekal bych, že by to bylo ze dne na den.

Nevšiml jsem si třeba, že by se na vývoji iproute2 nějak negativně projevilo, že Stephen Hemminger přešel do MS. Sasha Levin sice poslední dobou dělá dost podivné věci, ale ani tam si nemyslím, že byl to byla nějaká řízená sabotáž, IMHO to všechno myslí dobře.

[Grunt]

A jinak je to také velice dobrý čas na sebereflexi. Vím že to bude znít krutě, ale jestli je možné zastavit vývoj otevřeného softwaru (a nebo aspoň velice znepříjemnit, dovedu si představit následky když by se GitHub ze dne na den zastavil) jednou blbou akvizicí, pak si asi otevřený software nezaslouží nic jiného než ten krchov…

[kralyk z abclinuxu]

Tak já nevím jaké z toho máš pocity ty, ale výjimkou VS code mi přijde prakticky veškerý SW od MS totálně na kokot. Vzhledem k tomu, co udělal ostatním sežraným službám si troufám pochybovat, že by GH zůstal stejně použitelným, i kdybych náhodou chtěl hostovat zrovna u MS z filosoficko-morálních důvodů.

To souhlasim, ale čekal bych, že u GH si MS tolik nedovolí, vzhledem k tomu, jak masivně to je mezi vývojáři populární. Myslim si, že třeba se Skypem se to nedá úplně srovnat.

Třeba takové Go má ekosystém víceméně založený na Gihubu (hardcodované github repos coby dependence), což je trochu retardovaný, ale tak to maj...

Ale samozřejmě je možné, že s tim MS udělá něco špatnýho, a pak bych i nějaký odliv očekával.

A ty o nějakém víš? Já nic nenašel.

Ne, nevim, spíš jsem uvažoval nad využitím jednak federativních sociálních sitích (Mastodon, Diaspora, ...) a jednak alternativ ke GitHubu (hlavne GitLab), které není kdovíco.

Ten požadavek není, aby ta alternativa pouze existovala a měla vhodnou implementaci, ale aby taky měla šanci stát se populární. Což je mnohem těžší.

[Michal Kubeček]

nic nebudou rozšiřovat

Ale budou… :-)

[xvasek]

Slabší povahy neklikat, je to děsivé!

[Max]

Pan sponka je pořádnej pán !!!
Zdar Max

[kyytaM]

NSFW!

[pc2005]

Noooooo! Popřípadně god please no!

[Bystroushaak]

Shivaxi - Vader's NOOOO DnB Remix (Star Wars)

[mankind_boost]

ayy, to jsem rad ze nekdo tenhle malej kanal taky zna

[Bystroushaak]

Tak já jeden čas poslouchal psydnb docela dost. Shivaxi, Xenofish, Mellow sonic / Synesthesic, Cybernetika, Cryomatter, Ra Djan, Antibreak.

[Jendа]

Jako bych to slyšel: To, že mají se všemi uživateli uzavřeno v ToS, že se za ně budete soudit v Kalifornii, přece nevadí, protože GitHub nevlastní žádná evil firma, která by vám chtěla něco zlého udělat. A git je decentralizovaný, není přece nejmenší problém kdykoli odejít.

[pc2005]

Buildroot (sestaví obvykle embedded distribuci, ale obsahuje i heavy stuff jako Xka, GTK a QT, multimedia i python ()), asi rok starý snapshot:

# grep -r -n -i --include=*.mk "github" ./package | wc -l
565