DMCA požadavek na zastavení šíření zdrojových kódů youtube-dl na GitHubu

RIAA (Recording Industry Association of America) podala DMCA požadavek (DMCA takedown notice) na zastavení šíření zdrojových kódů youtube-dl na GitHubu. Pomocí youtube-dl lze z YouTube stáhnout autorská díla určená pouze pro YouTube.

23.10.2020 22:22 | Ladislav Hagara | Komunita

Komentáře

[Tom]

Nejen požadavek. Github repozitáře odstřelil.
Osobně to nepovažuji za problém, prostě se opět část věcí přesune ze Spojených Států do Ruska.

[Tom]

Divím se, že FSB se nesnaží využívat takových tendencí víc...
To už je druhá příležitost, kdy mohli přetáhnout část lidí z Githubu pod svou kontrolu.

[mica]

Jak se to dotkne repozitářů linuxových distribucí?

[Fluttershy, yay!]

Pamětníci vzpomenou, že např. Mint měl ještě před několika lety zvlášť obrazy pro USA a zbytek světa: bez kodeků a s nimi. Potažmo analogické repozitáře napříč distribucemi (Packman, RPMFusion,… asi furt existují).

[marbu]

Projekt RPM Fusion stále existuje, a spravuje 2 repozitáře:

• free, který obsahuje balíčky co by nešlo v USA distribuovat kvůli patentům (např. ty free software implementace patentovaných kodeků)
• nonfree, který obsahuje software který z nějakého jiného důvodu nesplňuje Fedora packaging policy (nejde o free software, např. steam nebo nvidia binárky)

Řekl bych ale, že v tomto případě jde o zcela jiný problém: tady se RIAA přes DMCA snaží přímo útočit na vývojáře, ne na distribuce.

[Radovan]

Jednou jsem takhle zkoumal, jestli je v youtube-dl podpora pro RT.com a nebyla, což mi přišlo divné... A pak jsem si všiml, že přímo u videa na RT.com je ikonka se šipkou a tooltipem "Download", která funguje přesně tak, jak by člověk čekal.

Takže takhle se to dělá. Tady bychom se měli učit.

[kotrcka]

Učiť?

Ale YouTube nechce aby ľudia tie videá sťahovali, chce aby ich sledovali na stránke / v aplikácii.

Alebo si fakt myslíš že nie sú schopní tam "šipku Download" pridať?

[Peter Golis]

A keby dostali zaplatené od užívateľa za stiahnutie toľko ako dostanú za zobrazenie tej otravnej reklamy, tak by boli ochotní tam tú šípku Download dať?

[kotrcka]

Nie. A vieš prečo?

[Peter Golis]

Viem, mali by z toho len jednorázový zisk. V súčasnom koncepte môžu predávať informácie o sledovaných ľuďoch do nekonečna.

[jiwopene]

Údajně tam je, ale za poplatek.

[xkucf03]

Přílohy:

• Screenshot_2020-10-23 github dmca.png (605530 bytů)
• Screenshot_2020-10-23 ytdl-org youtube-dl.png (99717 bytů)

Pro záznam dávám snímky obrazovky do přílohy.

Jinak, co k tomu říct? Snad jen: já jsem vám to říkal…

Support and promote decentralized social networks and developer infrastructure., Zálohujeme internet: Zdrojové kódy, A ani stát by je neměl podporovat…, Podezřelá přesměrování z GNU.org na GitHub, Taky to běží v USA a podléhá jejich právu (patenty, jejich výklad copyrightu…) a mnoho jiných komentářů.

[Honza]

Jak se dostali k seznamu privátních repozitoří, které obsahují youtube-dl kód ? Jsem měl za to, že privátní repozitoř znamená, že tam mají přístup pouze uživatelé schválení vlatníkem danného repa.

[xkucf03]

Ten řádek „[private]“ nemusel být nutně privátní repozitář – stejným způsobem jsou v tom dopise „začerněné“ i jiné údaje jako jména nebo telefonní čísla. Ale fakt nevím, proč by zrovna ten jeden repozitář neuvedli.

Jinak je to ale celkem jedno – když se GitHub rozhodne spolupracovat, tak smaže pravděpodobně všechno a třeba i zamezí opětovnému nahrání. Jestli je repozitář privátní nebo ne, na tom moc nesejde – GitHub do něj vidí a různé automatické detekce na něm budou fungovat úplně stejně.

[Tom]

Bittorent problémy se zákony nemá?
Ad hosting ve svobodnějších zemích: ano.

[xkucf03]

Problémy má teoreticky každý, na koho dosáhne daná legislativa – bez ohledu na technologii.

Výhoda decentralizovaných technologií je v tom, že nestačí zatlačit na jednu velkou firmu nebo několik málo firem – bylo by potřeba útočit na spoustu malých subjektů a jednotlivců a někdy je nejde ani dohledat. Takže to vytváří jistou imunitu. Oproti tomu požádat o „spolupráci“ Microsoft, Google, Facebook atd. je snadné.

V případě BitTorrentu lze útočit buď na centrální body (různé vyhledávače nebo trackery) nebo na jednotlivé uživatele sdílející konkrétní „závadná“ data. Vyhledávání a metadata představují minimální objem, takže se to snadno skryje případně to jde taky decentralizovat. Jednotliví uživatelé se občas řeší, např. u nás ve škole občas chodily e-maily, že ta a ta IP adresa sdílela nějaký film. Na to byla většinou odpověď, že šlo o zavirovaný počítač, který jsme odvirovali a dál se to neřešilo. Zátahy se dělají jen na velké ryby, které toho sdílejí hodně (a jde o prokazatelné porušení autorského práva – např. ty filmy nebo nedejbože pirátský software). Ale je nereálné, že by někdo obcházel po jednom všechny uživatele, kteří přes BitTorrent sdílí zdrojáky youtube-dl nebo jiného svobodného softwaru, který někdo považuje za „závadný“.

Celkově tahle akce bude mít za následek spíš jen Streisand effect. Jak už jsem někde psal:

I already had youtube-dl mirrors, but now I have even more youtube-dl mirrors :-)

A pokud budu optimista, tak snad následkem bude i to, že se lidi začnou víc zajímat o decentralizované technologie nebo víc přemýšlet, jaký (byť centralizovaný) hosting si vyberou.

[Tom]

Nevýhoda decentralizované architektury je, že policie bude klepat na tvoje dveře.
No vidíš, už se začínáš dostávat k tomu, jak to reálně funguje s postihováním bittorentu. Teď se ještě podívat, jak to funguje v méně svobodných zemích, než je ta naše, a nastudovat si případy jiných závadných programů, jako jsou například nástroje na odstraňování DRM

[kralyk z abclinuxu]

Jinak, co k tomu říct? Snad jen: já jsem vám to říkal…

Z mého pohledu: Neříkal. Já jsem to říkal Vysvětlim...

Ty máš problém hlavně s tím, že GitHub je proprietární centralizovaná služba. To, že je proprietární, nemá s tímhle problémem společného vůbec nic. Úplně stejnému riziku je vystavena v USA i jakákoli svobodná služba.

To, že je centralizovaná, souvisí částečně. Ono by totiž stačilo, kdyby byla centralizovaná v jiné jurisdikci. Pokud by byla decentralizovaná, mohlo by to pomoct, ale ta decentralizace by musela být implementovaná dobře, aby byla skutečně odolná proti právnickým útokům. A navíc pak je problém v tom, že s odsunem většího počtu lidí na takovou službu by zcela jistě nastal poměrně nepříjemný 'závod ve zbrojení' s vládami zemí. Ono pak stačí, když vlády lidem používaní decentralizované technologie dostatečně znepříjemní (viz třeba bitcoin), a tím zajistí, že je bude používat pouze velmi malá část lidí.

A tím se dostáváme k jádru problému: Jsou to zákony v USA a obdobné zákony v mnoha jiných zemích. A za povšimnutí stojí, že za těmi zákony je do značné míry lobby olygopolu firem. Což jsi fakt neříkal, naopak dlouhodobě popíráš vůbec existenci tohoto problému.

Proč místo toho vedeš svatou válku proti uživatelům githubu za to, že se v tržním prostředí chovají tržně je doublethink, který dlouhodobě nechápu...

Btw., z odkazovaného komentáře:

to se prostě nestane, pokud neuděláš nějakou vyloženou provokaci typu zveřejnění cracku na produkt velké korporace na githubu

... takže ještě Jenda to říkal ...

[xkucf03]

To, že je proprietární, nemá s tímhle problémem společného vůbec nic.

Proprietárnost je reálný problém ve chvíli, kdy přestaneš být s daným provozovatelem spokojený a budeš se chtít přesunout třeba do jiné země nebo jen na vlastní servery (které budou spravovat správci, kterým věříš víc). Přijdou lidi jako Bystroušák a začnou remcat, že to nejde, a že novému řešení chybí nějaké funkce nebo UI toho původního proprietárního. Když to bude svobodný software, tak tenhle problém odpadá, protože nový hosting bude pro uživatele z hlediska funkcí a UI naprosto stejný.

Taky dlouhodobě radím používat vlastní domény a nevázat se na doménu poskytovatele (např. github.com, twitter.com, facebook.com) a neodvozovat z ní „svoje“ jmenné prostory (netýká se to jen odkazů, ale třeba i názvů balíčků nebo jiných identifikátorů). Taky dlouhodobě říkám, že by to mělo být federalizované – jako např. e-mail nebo XMPP – to řeší ty „sociální“ otázky.

Úplně stejnému riziku je vystavena v USA i jakákoli svobodná služba.

Nikdo tě nenutí provozovat servery v USA. Když např. píšu o tom, že by FSF měla na těchto věcech pracovat, tak to neznamená, že by se FSF (sídlící v USA) měla stát nějakým (centrálním) poskytovatelem těchto služeb. Znamená to, že by měla navrhovat standardy, protokoly a vytvářet ten software – dát lidem nástroj a ukázat jim cestu. Ten software pak může provozovat kdokoli kdekoli na světě.

Ono pak stačí, když vlády lidem používaní decentralizované technologie dostatečně znepříjemní (viz třeba bitcoin), a tím zajistí, že je bude používat pouze velmi malá část lidí.

Proto je potřeba, aby danou technologii používalo co nejvíc lidí. Zakázat něco, co je všeobecně oblíbené a co používají skoro všichni, moc dobře nejde. Taky dost pomáhá, aby většina využití byla legální a legitimní. Např. já stahuji obrazy GNU/Linuxových distribucí prakticky vždy přes BitTorrent. Nepoužívám tuhle technologii k pirátskému stahování autorských děl. Stejně tak většina lidí si nožem krájí chleba a jen sem někdo někoho pobodá. Většina lidí jezdí autem do práce a na nákupy a jen občas se najde zločinec, který někoho cíleně přejede. Proto je důležité, aby ty decentralizované technologie používalo co nejvíc normálních lidí k běžným neškodným účelům (i tam, kde by šlo použít ten GitHub a zdánlivě by to ničemu nevadilo), aby to nebyla výsada jen nějakých paranoidních pošuků, které si stát může dovolit šikanovat, protože většina lidí danou technologii nepoužívá a je jim to jedno, nebo o tom nikdy neslyšeli a nechápou to.

Ty jako programátor máš oproti většinové veřejnosti výhodu a máš možnost to ovlivnit. Ale když na to i lidi jako ty rezignují a půjdou tou pohodlnější cestou, tak se těžko něco něco změní k lepšímu. Už jsem ti to psal v té předchozí diskusi:

Když budeš jen sedět a dumat nad tím, co by mohlo a mělo být, tak se to nikdy nestane, ty věci se samy od sebe nezlepší. Teprve když ty nástroje začneš používat a tu činnost vykonávat, tak je šance, že se to někam posune a zdokonalí.

Ještě nikdy se nic nezlepšilo samo tím, že na to lidi jen koukali a říkali, že to nejde.

Jazyková poznámka: nauč se prosím psát slovo oligopol, všiml jsem si toho u tebe už víckrát, píše se tam měkké i, ne y.

A tím se dostáváme k jádru problému: Jsou to zákony v USA a obdobné zákony v mnoha jiných zemích. A za povšimnutí stojí, že za těmi zákony je do značné míry lobby olygopolu firem.

Autorské právo jako takové není problém, ten koncept je v pořádku. Problém je, když se na něj nabalují další zákony a nařízení, které jdou proti jiným právům a svobodám. Předpokladem je dostatečně silná a dobře napsaná ústava, která takovému zneužívání a ohýbání zabrání. Analogicky: je špatné zasahovat lidem do soukromí, brát jim svobodu slova, presumpci neviny nebo právo se bránit se zbraní v ruce – ale to neznamená, že by se např. mělo legalizovat zneužívání dětí, vytváření dětské pornografie¹ nebo vraždění lidí. Fakt, že si někteří berou tyto zločiny jako záminku k omezení svobody, nelze brát jako argument pro legalizaci těchto zločinů.

Proč místo toho vedeš svatou válku proti uživatelům githubu za to, že se v tržním prostředí chovají tržně je doublethink, který dlouhodobě nechápu...

Já bych tomu neříkal „svatá válka proti uživatelům“. Uživatelům říkám, že by se měli zamyslet, koho svým chováním podporují a zda náhodou v dlouhodobějším horizontu neubližují i sami sobě. Týká se to třeba i toho YouTube. Chce to víc domýšlet následky. I když máš pocit, že tobě přímo to neškodí, že reklamy přeskočíš, že se jako autor nenecháš korumpovat atd. tak i když to dokážeš, tak stále svojí přítomností podporuješ danou platformu. A tady je právě otázka, jaký chceme mít internet – jestli chceme, aby byla (skoro) všechna infrastruktura a hlavně moc centralizována u několika málo subjektů, velkých korporací, které navíc sídlí ve stejné zemi a podléhají stejné jurisdikci.

_{[1] a tím myslím tu skutečnou, při které dochází ke zneužívání dětí, ne nějakou domnělou, kde jsou dospělí herci a herečky nebo je to dokonce jen kreslené}

[Bystroushaak]

Přijdou lidi jako Bystroušák a začnou remcat, že to nejde, a že novému řešení chybí nějaké funkce nebo UI toho původního proprietárního.

Já třeba v tomhle případě neremcám ani tak na nějaké UI, ale na to že git je nedodělek*, který myslel jen na jednu věc. Kdyby v sobě jako protokol měl podporu i pro ty ostatní, nebo obecně pro rozšiřitelnost, tak tenhle problém z velké části odpadne**. Tohle je jak kdyby email uměl poslat jen tělo emailu, ale veškeré další hlavičky by se musely zajišťovat jinak (určitě by se našel někdo hrozně chytrý, kdo by ti poradil ať je dáš do těla, nebo jako přílohu, nebo pošleš dalším emailem). Automaticky to vede na tříštění implementací. Přitom tady máš protokol, který umí řešit konflikty a decentralizovaně se synchronizovat. Nechápu, proč tam ta podpora pro diskuze, issues a tak dál dávno není.

* To není myšleno tak pejorativně, jak to zní. Prostě tam určité věci nejsou, chápu historický kontext proč, ale pořád nesouhlasím s tím že tam nejsou.

**Než mi zase někdo začne cpát že si můžu implementovat wiki a diskuze nad gitem, tak bych rád tuhle větev diskuze rovnou zarazil. Tady nejde o mě, ale obecně o lidi / o používání. A to očividně ukazuje nějakou potřebu a že git jí momentálně nenaplňuje.

[xkucf03]

neremcám ani tak na nějaké UI, ale na to že git je nedodělek*, který myslel jen na jednu věc. Kdyby v sobě jako protokol měl podporu i pro ty ostatní…

Tady musím zmínit Fossil (používá ho např. SQLite), který v sobě integruje i wiki a systém na správu požadavků/chyb. Takže když si uděláš klon repozitáře, tak máš u sebe i ty hlášené chyby/požadavky, dokumentaci atd.

Srovnej si to se situací na GitHubu – když se stane to, co se stalo youtube-dl teď, tak většina uživatelů bude jen zmateně koukat a divit se, že jim všechno zmizelo. Zdrojáky asi u sebe na disku najdeš, ale ty ostatní věci většina lidí nijak nezálohuje a spoléhá se na magický „cloud“ od kterého naivně očekávají, že bude vždy dostupný. Další věc jsou ty jmenné prostory – odvozovat je z github.com/login/projekt je vážně hloupé a lidem se to vymstí. I kdyby ti momentálně GitHub jako poskytovatel vyhovoval, tak vázat se na něj tímto způsobem je blbost.

Ještě k těm verzovacím systémům: nelíbí se mi, že si spousta lidí myslí, že „verzování = git“ a učí tohle i ostatní. Proto se taky snažím dlouhodobě propagovat, že existují i jiné VCS a že bychom k tomu měli přistupovat trochu obecněji a nefixovat se na jednu konkrétní implementaci (Git).

[Bystroushaak]

Tady musím zmínit Fossil (používá ho např. SQLite), který v sobě integruje i wiki a systém na správu požadavků/chyb. Takže když si uděláš klon repozitáře, tak máš u sebe i ty hlášené chyby/požadavky, dokumentaci atd.

Díky. Vím že to existuje, jen jsem to nikdy nezkoušel. Posunu to v žebříčku priorit výš. Čistě pro zajímavost, v nodě Iterativní explorace, odkud postupně tahám věci k prozkoumání, mám na téma VSC:

• http://radicle.xyz/
• https://www.fossil-scm.org/home/doc/trunk/www/index.wiki
• http://gameoftrees.org/
• https://pijul.org/
• http://darcs.net/
• https://gitless.com/

Srovnej si to se situací na GitHubu – když se stane to, co se stalo youtube-dl teď, tak většina uživatelů bude jen zmateně koukat a divit se, že jim všechno zmizelo. Zdrojáky asi u sebe na disku najdeš, ale ty ostatní věci většina lidí nijak nezálohuje a spoléhá se na magický „cloud“ od kterého naivně očekávají, že bude vždy dostupný. Další věc jsou ty jmenné prostory – odvozovat je z github.com/login/projekt je vážně hloupé a lidem se to vymstí. I kdyby ti momentálně GitHub jako poskytovatel vyhovoval, tak vázat se na něj tímto způsobem je blbost.

Já s tímhle souhlasím, přestože poněkud pokrytecky, protože sám github extenzivně používám. Rád bych ovšem přešel na něco víc decentralizovaného.

[kralyk z abclinuxu]

Pijul můžeš posunout někam dolů, bohužel. Jednak je to dost mrtvý, vývoj se nehejbe (a jsou tam bugy, když jsem to zkoušel, občas to panikovalo), a jednak to nemá ty věci navíc jako issue tracking, nejsou součástí repa. Ty jsou implementovaný v tom webovým interface ("Nest"), keterej (aktuálně) ani není open source.

[marbu]

Tohle je jak kdyby email uměl poslat jen tělo emailu, ale veškeré další hlavičky by se musely zajišťovat jinak (určitě by se našel někdo hrozně chytrý, kdo by ti poradil ať je dáš do těla, nebo jako přílohu, nebo pošleš dalším emailem).

Teď jsem trochu off topic, ale ono to takto nějak funguje. Protokol SNMP umí jen základní hlavičky a asci tělo zprávy. Přílohy nebo cokoli jiného (např. odlišné kódování nebo html zprávy) řeší MIME, kterým se zpráva v ne ascii formátu zakóduje do jedné dlouhé ascii zprávy :)

Přitom tady máš protokol, který umí řešit konflikty a decentralizovaně se synchronizovat. Nechápu, proč tam ta podpora pro diskuze, issues a tak dál dávno není.

To je dáno tím, že Linus git navhrnul primárně pro potřeby vývoje Linuxového jádra, jehož vývojáři jako decentralizovaný nástroj pro zasílání změn, vedení diskusí a review používají zavedení protokol: email (btw bez MIME . A řekl bych, že tak velkého projektu jako je Linux to funguje líp než Github like webové rozhraní.

Viz např. Git is already federated & decentralized

Tím ale neříkám, že ty aktivity kolem ForgeFed protokolu nemají smysl, naopak je považuju za užitečné.

[Fluttershy, yay!]

Na druhé straně se lidi kolem jádra snaží nahradit e-mailové konference.

[xkucf03]

A tím se dostáváme k tomu, co už jsem tu psal:

Když budeš jen sedět a dumat nad tím, co by mohlo a mělo být, tak se to nikdy nestane, ty věci se samy od sebe nezlepší. Teprve když ty nástroje začneš používat a tu činnost vykonávat, tak je šance, že se to někam posune a zdokonalí.

Až to reálné používání to může posunout někam dál. Buď se ukáže, že e-mailové konference vyhovují, nebo se vyvine něco lepšího. Ale lidi, kteří říkají, že by se měl používat GitHub, dokud nebude něco „lepšího“ situaci nijak neprospívají, protože samo od sebe nic lepšího nevznikne.

[Fluttershy, yay!]

Na tom, že e-mailové konference jsou nevyhovující, je široký konsenzus: důkazem je popularita GitHubu nebo snaha se e-mailu zbavit při vývoji Linuxu. Což také ukazuje, že GitHub někde/někomu vyhovuje a někde/někomu ne.

[xxx]

Ja mel za to, ze v pripade Linuxu, je to tak nastaveno naschval, aby to odradilo slabsi kusy od prispivani. Protoze ten, kdo si nedokoaze ten silenej proces pomoci ruznych nastroju zautomatizovat tak, nemuze ani vyprodukovat dobry patch do jadra.

[marbu]

Kteří jaderní vývojáři by se chtěli zbavit stávajícího workflow, protože jim nevyhovuje? Já to nesleduju aktivně, ale měl jsem dojem, že mezi jadernými vývojáři panuje shoda, že email je aktuálně nejlepším způsobem jak organizovat vývoj. Viz Why kernel development still uses email (pravda z roku 2016, ale situce je imho stále stejná):

In short, Greg said, kernel developers still use email because it is faster than any of the alternatives. Over the course of the last year, the project accepted about eight changes per hour — every hour — from over 4,000 developers sponsored by over 400 companies. It must be doing something right. The list of maintainers who accepted at least one patch per day contains 75 entries; at the top of the list, Greg himself accepted 9,781 patches over the year. Given that he accepts maybe one third of the patches sent his way, it is clear that the patch posting rate is much higher than that.

In summary, Greg said, email matters because it is simple, supports the widest group, and is scalable. But the most important thing is that it grows the community. When new developers come in, the first thing they have to do is to learn how the project works. That includes reading the reviews that developers are doing; that is how one learns what developers care about and how to avoid mistakes. With the kernel, those reviews are right there on the mailing list for all to see; with a system like Gerrit, one has to work to seek them out.

Zachytil jsem náznaky, že vzhledem k popularitě githubu a webových služeb obecně, může být dnes email workflow na překážku novým přispěvatelům, viz. např. Relying on plain-text email is a 'barrier to entry' for kernel development, says Linux Foundation board member, ale zrovna u linuxového jádra bych řekl, že naučit se poslat patch emailem je ten z menších problémů, co musí jeden překonat při začátcích s jaderným vývojem. O organizaci jaderného vývoje navíc rozhodují jaderní vývojáři, ne Linux Foundation Board.

Github je populární protože přinesl jednoduché webové rozhraní postavené nad gitem, které je pro spustu projektů stravitelnější a rychlejší na používání. Ale řekl bych, že čím je projekt větší, tím víc naráží na omezení tohoto přístu. Ale jak píšeš, to je individuální projekt od projektu.

[Fluttershy, yay!]

Např. Next steps for kernel workflow improvement

[marbu]

Dík za odkaz. Čtu to ale tak, že případné zlepšení stávajícího workflow by mohlo stávající systém doplnit, ale ne nahradit:

The meeting was organized and led by Konstantin Ryabitsev, who is in charge of kernel.org (among other responsibilities) at the Linux Foundation (LF). Developing the kernel by emailing patches is suboptimal, he said, especially when it comes to dovetailing with continuous-integration (CI) processes, but it still works well for many kernel developers. Any new processes will have to coexist with the old, or they will not be adopted.

... there is desire for a solution that could let some developers move beyond email while maintaining the current workflow overall. The first step in that direction is likely to be some sort of Git-to-email bridge.

[marbu]

Tím pádem ale tvrdit že existuje snaha se e-mailu zbavit při vývoji Linuxu je trochu zavádějící.

[Fluttershy, yay!]

To by mohlo vést na podobnou výměnu jako vedle s gitem jako protokolem, programem nebo čertvíčím.

Tedy: co přesně se rozumí „e-mailem“ a kdy je to ještě pořád „e-mail“? (Podobná situace je vlastně kolem IM protokolů a jejich využití v různých produktech.)

[marbu]

Mě šlo hlavně o tu čás "zbavit se". Tak to na mně opravdu nepůsobí. Btw "email" je v tomto kontextu jasně definován jaderným worklow.

[Fluttershy, yay!]

také výše ve vlákně: e-mailové konference, resp. „feeds“ v odkazovaném článku

[Michal Kubeček]

Kteří jaderní vývojáři by se chtěli zbavit stávajícího workflow, protože jim nevyhovuje?

V podstatě nikdo - nebo aspoň ne nikdo, na kom by záleželo. To si kolega realitu dost přibarvil k obrazu svému.

O čem se opravdu diskutuje, a i to jen v některých subsystémech, je idea nějaké github-like nadstavby jako alternativy ke klasickému e-mailovému workflow pro ty, kterým nevyhovuje. Zatím to ale vždy předpokládalo, že by to muselo být propojené tak, aby ten, kdo bude používat výhradně e-mail, nebyl nijak diskriminován.

Jinak nějaké nadstavby už se někde používají, třeba Patchwork (a ještě jeden) pro management patchů. Oproti tomu bugzilla sice existuje, ale většina vývojářů ji nesleduje.

A ještě perlička: ani samotný git není přijímaný úplně univerzálně, třeba Andrew Morton na něj pořád ještě nepřešel.

[kralyk z abclinuxu]

Ale lidi, kteří říkají, že by se měl používat GitHub, dokud nebude něco „lepšího“ situaci nijak neprospívají, protože samo od sebe nic lepšího nevznikne.

Jestli to je narážka na mě, tak to je těžké nepochopení. Já neříkám, že by se měl používat GitHub, dokud nebude něco „lepšího“, já říkám, že lidi realisticky GitHub prostě používat budou, dokud nebude něco, co vyhodnotí jako lepší. Prostě je nepřesvědčíš. To je to, co říkám.

Jestli "by to tak být mělo" nebo "nemělo" na to nemá vůbec žádný vliv, to jsou hypotetické úvahy, to je takové co by kdyby. Kdyby si jen lidi rozmysleli používaní GH... Kdyby tohle, kdyby támhleto...

[Bherzet]

Já zas nevidím důvod, aby VCS řešil issues, wiki a diskuze. Můžeš standardizovat nějaký adresářový layout (např. adresář issues, kde budou tickety a diskuze o nich), ale zasahovat přímo do Gitu mi přijde hodně nešťastné.

Je to úplně oddělená doména problémů a integrace je v tomto případě dost triviální. Např. do commitu napíšeš číslo ticketu a Stash ti z toho pak udělá odkaz do Jiry. Ano, chybí pak integrace v některých nástrojích (např. gitk nebo IDE), ale to je problém právě toho chybějícího standardu/konvence, ne Gitu jako takového. Navíc Git není protokol, jak píšeš, ale opravdu jen program, který řeší verzování souborů.

Ten monolitický návrh, který prosazuješ, by měl za následek, že by (možná) vznikl software, který by vyhovoval tobě, ale ostatní, kteří by měli jiné požadavky – buď by některé funkce vůbec nepotřebovali, nebo by měli jiná očekávání (a že věci jako ploché/stromové diskuze, používaný markup atd. jsou dost kontroverzní) – by od něj kvůli přílišné komplexitě utíkali. On ne každý bude chtít používat to jedno IDE, které nad tím jedním VCS implementuje ten jediný issue tracker, jediný kanban a jedinou wiki. A kdyby to nebyl jeden monolitický kus software? No, tak to už pak ale přece ztrácíš ty domnělé největší výhody: že když si v IDE budeš prohlížet historii commitů, tak se „nebudeš“ moct prokliknout na issue a pročíst si tam diskuzi. Já vím, to není úplně pravda: mohl bys to udělat úplně stejně, jako můžeš teď (třeba přes nějaký plugin), akorát v jiném softwaru (webovém koukátku apod.).

Za mě je úspěch Gitu právě v tom, že je to jeden relativně malý, ale mocný program, který řeší jediný problém a řeší ho extrémně dobře. Ten nářek na absenci rozšiřitelnosti zrovna nechápu vůbec, protože zrovna s Gitem je právě díky té jeho rozumné koncepci možno pracovat na tisícero způsobů: můžeš s ním pracovat přes CLI, přes GUI (gitk, gitg, integrace do různých IDE vč. implementací v jiných jazycích) a i v tom oficiálním příkazovém rozhraní si můžeš vybrat vlastní editor pro editování zpráv při commitování, pro řešení merge konfliktů atd.

[Bystroushaak]

Já zas nevidím důvod, aby VCS řešil issues, wiki a diskuze. Můžeš standardizovat nějaký adresářový layout (např. adresář issues, kde budou tickety a diskuze o nich), ale zasahovat přímo do Gitu mi přijde hodně nešťastné.

Sigh. To je ale přesně to co jsem psal; protože můžeš všechno, nebude nic, což vede na služby typu github, které ten počet možností omezí na nějaké jejich vlastní řešení a zapláčem na tom všichni.

Ten monolitický návrh, který prosazuješ, by měl za následek, že by (možná) vznikl software, který by vyhovoval tobě, ale ostatní, kteří by měli jiné požadavky – buď by některé funkce vůbec nepotřebovali, nebo by měli jiná očekávání (a že věci jako ploché/stromové diskuze, používaný markup atd. jsou dost kontroverzní) – by od něj kvůli přílišné komplexitě utíkali.

Tak se nad tím zkus zamyslet znova, protože tohle fakt nedá zas tak moc práce vymyslet. Mohl bys například navrhnout linked-list protokol obecně na sebe navazujících nod a tím implementovat cokoliv od wiki, přes issue, diskuze a já nevím co dalšího. Pak tomu dodat nějaké templaty a základní commandline rozhraní a máš to. Verzovat to pak můžeš v rámci stejné historie commitů, nebo třeba nějak vedle.

A kdyby to nebyl jeden monolitický kus software?

Já jsem se ale vůbec nebavil o software, ale o protokolu. To je rozdíl. Vůbec nevím co tu vymýšlíš s tím jedním IDE. Git je protokol už teď a můžeš k němu přistupovat z několika různých nástrojů.

Za mě je úspěch Gitu právě v tom, že je to jeden relativně malý, ale mocný program, který řeší jediný problém a řeší ho extrémně dobře. Ten nářek na absenci rozšiřitelnosti zrovna nechápu vůbec, protože zrovna s Gitem je právě díky té jeho rozumné koncepci možno pracovat na tisícero způsobů: můžeš s ním pracovat přes CLI, přes GUI (gitk, gitg, integrace do různých IDE vč. implementací v jiných jazycích) a i v tom oficiálním příkazovém rozhraní si můžeš vybrat vlastní editor pro editování zpráv při commitování, pro řešení merge konfliktů atd.

Tady útočíš na strawmana něčeho, co jsem vůbec nepsal. Github má momentálně přes 40 milionů uživatelů, mnoho organizací na něm staví celou infrastrukturu a delivery pipeline. To je problém, protože viz třeba te youtube-dl, ale obecně prostě data co jdou MS taky nejsou žádná radost. V podstatě jsme se jako civilizace rozhodli záviset na jedné firmě pro velmi velké procento opensource softwaru.

Github existuje jen a protože umožňuje a usnadňuje věci, které git buď vůbec neumí, nebo existuje sto možností jak je dělat, nebo je umí, ale složitě. Cesta z toho ven je nezáviset na jedné firmě, a ideálně nezáviset na žádné firmě. Člověk může vymýšlet různé decentralizovanosti, ale momentálně prostě máme super decentralizovaný git, akorát prostě neumí co většina lidí chce.

[Bherzet]

Sigh. To je ale přesně to co jsem psal; protože můžeš všechno, nebude nic, což vede na služby typu github, které ten počet možností omezí na nějaké jejich vlastní řešení a zapláčem na tom všichni.

Ty sis stěžoval, že Git je nedodělek, protože neřeší issue tracker a diskuze, a já ti vysvětloval, proč si nemyslím, že by to měl řešit přímo Git samotný. Github je hosting a kolaborační platforma postavená nad Gitem. Fakt nechápu souvislost.

Jestli tvoje úvaha byla taková, že Git už přece je decentralizovaný, tak by nad to stačilo našroubovat ještě ten issue tracker a diskuze a voilà, služby typu Github by nebyly potřeba, tak to mi přijde jako úplné nepochopení fungování Gitu. Git nemá nijak vyřešený ten protokol, jak tu pořád píšeš. Pokud bys chtěl někomu umožnit, aby do repozitáře na tvém serveru mohl pushnout komentář, musel bys mu prvně dát přístup třeba přes SSH (většinou se to řeší přes uživatele git, který má jako shell nastavený git-shell). A nebude to tam pak ani jako „pull request“, což je inovace Githubu, ale rovnou se ti to tam objeví jako commit(y) v patřičných větvích.

Ty si stěžuješ na to, že se víc nerozšířila nějaká federativní platforma, která ten Github supluje. Absolutně to nesouvisí se samotným Gitem, který prostě nijak neřeší samotné publikování repozitáře (nemá žádného síťového daemona), neřeší přístupová práva k němu atd. Ten tvůj výrok, že „přitom tady máme protokol, který umí řešit konflikty a decentralizovaně se synchronizovat“, je prostě zcela mimo realitu. Není to protokol, neumí se to samo nijak zázračně synchronizovat a neumí to nijak řešit konflikty, na ty tě to jen upozorní. Pokud ten konflikt někdo bude chtít vyřešit tak, že všechno smaže a nechá tam jen svůj komentář, tak Git nemá žádný mechanismus, který by mu v tom zabránil.

Git řeší dobře tu úlohu, na kterou byl určen: verzovat soubory. S voláním po federativní kolaborativní platformě ve FOSS komunitě nejsi ani zdaleka osamocený a existují projekty, které se to snaží řešit (např. Gitea), ale vyčítat Gitu, že tohle všechno neimplementuje, je asi stejně relevantní jako si stěžovat, že kernel nemá vestavěnou podporu pro decentralizované sociální sítě, protože už stejně implementuje TCP/IP stack a ačkoliv je hezké, že si nad tím uživatelé můžou postavit, co chtějí, tak ve výsledku to skončí tak, že utečou na proprietární službu typu Facebook.

Mohl bys například navrhnout linked-list protokol obecně na sebe navazujících nod a tím implementovat cokoliv od wiki, přes issue, diskuze a já nevím co dalšího.

A ten low-level protokol, který umožňuje implementovat „cokoliv od wiki, přes issue, diskuze a já nevím co dalšího“ nějak sám magicky vyřeší, že ta data budou napříč decentralizovanými repozitáři sémanticky jednotná a lidi neutečou k projektům typu Github, kde nemusí napřed půl hodiny studovat, jak konkrétně v tomhle projektu přidat issue?

Pak tomu dodat nějaké templaty a základní commandline rozhraní a máš to.

Aha, takže to musí být jednotné. No, fajn. Tak teď už z toho Gitu teda jen udělat síťového daemona, pořešit ty detaily, co jsem vyjmenoval výše, a je to hotové.

Člověk by řekl, že by bylo lepší to postavit nad tím Gitem s tím, že by to tedy mohlo případně podporovat i jiné VCS než Git, protože drtivá většina té práce stejně s Gitem vůbec nesouvisí, a Git sám o sobě je použitelný i bez toho, takže nemá smysl to do něj srát, ale když teda za každou cenu monolit, no tak holt monolit.

Já jsem se ale vůbec nebavil o software, ale o protokolu. To je rozdíl. Vůbec nevím co tu vymýšlíš s tím jedním IDE. Git je protokol už teď a můžeš k němu přistupovat z několika různých nástrojů.

Ty navrhuješ z Gitu udělat protokol a nacpat do něj všechny tyhle funkce, přičemž výše jsme si ujasnili, že pokud má existovat nějaké jednotné CLI rozhraní, tak to musí být poměrně tvrdě standardizované. Sémanticky už nestačí vědět, že „tohle je soubor“, ale musí být strojově rozhodnutelné, že např. „toto je komentář, který reaguje na issue č. #1“.

Domníval jsem se, že když už bys chtěl Git tímto způsobem znásilňovat, tak proto, abys docílil lepší úrovně integrace: mít jedno IDE, ve kterém můžeš dělat veškerý vývoj (vč. správy ticketů, psaní poznámek apod.). Ano, nad tím protokolem by teoreticky mohlo vzniknout vícero implementací, ale netriviálně komplexní věci typicky mají jen jednu implementaci – tu oficiální.

Pokud se spokojíš se „špinavým“ řešením v podobě používání příkazových utilit, popř. později časem nějakých pluginů apod., tak znovu nechápu, proč je nutné Git tímto způsobem znásilňovat a dělat z něj něco úplně jiného, když v praxi by bylo mnohem snažší a mnohem jednodušší řešit to o vrstvu výše (tzn. v novém projektu), kde si můžeš vybrat k tomu účelu vhodný jazyk atd.

Tady útočíš na strawmana něčeho, co jsem vůbec nepsal.

Jakého strawmana? Psal jsem, že Git je malý program, který se soustředí na jednu věc. Ty mu přisuzuješ schopnosti („decentralizovaně se synchronizovat“), které vůbec nemá, aspoň ne ve smyslu relevantním pro tuhle diskuzi, a proto ti přijde, že by tam ty věci, které navrhuješ, šly přidat nějak snadno. Ale ne, nešlo.

To, co chceš, je projekt postavený nad Gitem, který by řešil tu síťovou část, přístupová práva (s tím souvisí ochrana proti spamu/floodování) atd. Tuhle službu by sis pak spustil na serveru a každý, komu bys dal URL, by mohl posílat komentáře, reportovat bugy a posílat patche. Ale znovu opakuji, že tohle má opravdu hodně daleko k tomu, co Git dělá teď. Je to úplně jiná doména, jiný druh problému. A existují snahy ten problém vyřešit, ovšem nikoliv modifikací samotného Gitu (naštěstí).

[Bystroushaak]

Ty sis stěžoval, že Git je nedodělek, protože neřeší issue tracker a diskuze, a já ti vysvětloval, proč si nemyslím, že by to měl řešit přímo Git samotný. Github je hosting a kolaborační platforma postavená nad Gitem. Fakt nechápu souvislost.

Už jsem několikrát zmiňoval, že git jako protokol, ne git jako program.

Jestli tvoje úvaha byla taková, že Git už přece je decentralizovaný, tak by nad to stačilo našroubovat ještě ten issue tracker a diskuze a voilà, služby typu Github by nebyly potřeba, tak to mi přijde jako úplné nepochopení fungování Gitu. Git nemá nijak vyřešený ten protokol, jak tu pořád píšeš. Pokud bys chtěl někomu umožnit, aby do repozitáře na tvém serveru mohl pushnout komentář, musel bys mu prvně dát přístup třeba přes SSH (většinou se to řeší přes uživatele git, který má jako shell nastavený git-shell). A nebude to tam pak ani jako „pull request“, což je inovace Githubu, ale rovnou se ti to tam objeví jako commit(y) v patřičných větvích.

Tak určitě, vysvětli mi mé nepochopení gitu. Možná je třeba pravděpodobnější, že mě zas tak moc nezajímá proč to v současnosti nejde a co se ti na tom nelíbí.

Jinak ten Fossil vypadá, jako že je přesně to co popisuji.

Ty si stěžuješ na to, že se víc nerozšířila nějaká federativní platforma, která ten Github supluje. Absolutně to nesouvisí se samotným Gitem, který prostě nijak neřeší samotné publikování repozitáře

Git ale řeší publikování repozitáře, přes SSH a HTTP.

Ten tvůj výrok, že „přitom tady máme protokol, který umí řešit konflikty a decentralizovaně se synchronizovat“, je prostě zcela mimo realitu.

Cože? Tohle je celá pointa gitu.

Pokud ten konflikt někdo bude chtít vyřešit tak, že všechno smaže a nechá tam jen svůj komentář, tak Git nemá žádný mechanismus, který by mu v tom zabránil.

Tohle má mnoho různých řešení, ale jinak souhlasím, že mechanismus pro automatické bezpečné posílání pull/merge requestu github stylem tam asi v současnosti není.

Aha, takže to musí být jednotné. No, fajn. Tak teď už z toho Gitu teda jen udělat síťového daemona, pořešit ty detaily, co jsem vyjmenoval výše, a je to hotové.

Je idiocie si myslet, že se to obejde bez nějakého RFC, či ekvivalentu, protože pak se to jen roztříští do milionu různých implementací a nebudeš mít žádnou interoperabilitu. Opět; bavíme se tu o protokolu, ne o konkrétní implementaci, ta může vypadat různě.

vyčítat Gitu, že tohle všechno neimplementuje, je asi stejně relevantní jako si stěžovat, že kernel nemá vestavěnou podporu pro decentralizované sociální sítě, protože už stejně implementuje TCP/IP stack a ačkoliv je hezké, že si nad tím uživatelé můžou postavit, co chtějí, tak ve výsledku to skončí tak, že utečou na proprietární službu typu Facebook.

Jasně, tak díky že jsi mi vysvětlil co můžu gitu vyčítat a co ne, máš u mě klíčenku.

A ten low-level protokol, který umožňuje implementovat „cokoliv od wiki, přes issue, diskuze a já nevím co dalšího“ nějak sám magicky vyřeší, že ta data budou napříč decentralizovanými repozitáři sémanticky jednotná a lidi neutečou k projektům typu Github, kde nemusí napřed půl hodiny studovat, jak konkrétně v tomhle projektu přidat issue?

Tak to asi očividně záleží na specifikách, že. Idea je ovšem taková, že klikneš někde v IDE/webu/gui na tlačítko "přidat issue" a ona se přidá. Jediný rozdíl je, že ne někam do externí databáze, ale přímo do repozitáře.

Aha, takže to musí být jednotné. No, fajn. Tak teď už z toho Gitu teda jen udělat síťového daemona, pořešit ty detaily, co jsem vyjmenoval výše, a je to hotové.

Slippery slope nedokazuje že něco nejde, jen že si to neumíš představit, nebo tě to z nějakého důvodu sere. Proč tě to sere?

Člověk by řekl, že by bylo lepší to postavit nad tím Gitem s tím, že by to tedy mohlo případně podporovat i jiné VCS než Git, protože drtivá většina té práce stejně s Gitem vůbec nesouvisí, a Git sám o sobě je použitelný i bez toho, takže nemá smysl to do něj srát, ale když teda za každou cenu monolit, no tak holt monolit.

Já fakt nevím co to tu pořád máš s těma monolitama. Monolitickou aplikací se většinou označuje aplikace bez komponent. Git jednak není monolitická aplikace už teď (oficiální distribuce v sobě má git gui, gitk a gitweb, send-email a bambilion dalších), ale taky se tu pořád bavím o protokolu.

Ty navrhuješ z Gitu udělat protokol a nacpat do něj všechny tyhle funkce, přičemž výše jsme si ujasnili, že pokud má existovat nějaké jednotné CLI rozhraní, tak to musí být poměrně tvrdě standardizované.

Já jsem si teda nic takového neujasnil a myslím si, že jednotné CLI rozhraní existovat nemusí. To co tě zajímá je libgit2 či ostatní implementace protokolu, to jestli si přidáš nějaký commandline fluff kolem je docela irelevantní.

Sémanticky už nestačí vědět, že „tohle je soubor“, ale musí být strojově rozhodnutelné, že např. „toto je komentář, který reaguje na issue č. #1“.

Sémanticky tohle nestačí už od začátku gitu, git je něco jako blockchain, jen bez automatické rezoluce konfliktů hlasováním minerů. A sémanticky je to úplně stejné, jako tohle je commit navazující na commit. Je to prostě blok navazující na blok, podepsaný nějakou identitiou.

Domníval jsem se, že když už bys chtěl Git tímto způsobem znásilňovat, tak proto, abys docílil lepší úrovně integrace: mít jedno IDE, ve kterém můžeš dělat veškerý vývoj (vč. správy ticketů, psaní poznámek apod.). Ano, nad tím protokolem by teoreticky mohlo vzniknout vícero implementací, ale netriviálně komplexní věci typicky mají jen jednu implementaci – tu oficiální.

Lidi nikdy nebudou používat jedno IDE.

Jakého strawmana? Psal jsem, že Git je malý program, který se soustředí na jednu věc. Ty mu přisuzuješ schopnosti („decentralizovaně se synchronizovat“), které vůbec nemá, aspoň ne ve smyslu relevantním pro tuhle diskuzi, a proto ti přijde, že by tam ty věci, které navrhuješ, šly přidat nějak snadno. Ale ne, nešlo.

Git není program soustředící se na jednu věc. Když už něco, tak Git jsou desítky podprogramů, které řeší všechno od grafického rozhraní po posílání emailu. To podstatné je pro tebe implementace protokolu, což může být oficiální distribuce gitu, libgit2, nebo třeba Dulwich (čistý python).

To, co chceš, je projekt postavený nad Gitem, který by řešil tu síťovou část, přístupová práva (s tím souvisí ochrana proti spamu/floodování) atd. Tuhle službu by sis pak spustil na serveru a každý, komu bys dal URL, by mohl posílat komentáře, reportovat bugy a posílat patche. Ale znovu opakuji, že tohle má opravdu hodně daleko k tomu, co Git dělá teď. Je to úplně jiná doména, jiný druh problému. A existují snahy ten problém vyřešit, ovšem nikoliv modifikací samotného Gitu (naštěstí).

Ne, to si ty představuješ, že já chci. Já "chci" (po nikom to ve skutečnosti nechci, pouze to kritizuji), aby metadata kolem projektu byly součástí gitu, ideálně separátně/separovatelně od běžných commitů.

[Bherzet]

Na tuhle diskuzi nemám náladu. Nebudu ti to rozebírat po větách a pořád dokola opakovat, že je píčovina po souborovém systému chtít, aby řešil něco jiného než ukládání souborů, a pokud chceš třeba sychronizaci dat po síti nebo jednotnou strukturu nějakých konkrétních dat, tak to má řešit nějaká vrstva nad tím.

Konkrétně jsem ti zdůvodnil, v čem spočívá problém s pushováním přes SSH, pokud bys tím chtěl nahradit Github. Vytrhnout naprosto z kontextu jednu větu a na tu odpovědět, že „Git řeší publikování repozitáře přes HTTP a SSH“, prostě není reakce, na kterou by šlo dál odpovědět.

Celá moje argumentace stála a stojí na tom, že:

• Pokud by Git zůstal v současné podobě, tj. bez síťového daemona, bez vlastního protokolu (nebo API) a uměl jen kopírovat soubory přes HTTP a SSH, tak přidání např. jednotného formátu pro issues a diskuze neodstraní důvod existence Githubu, protože bys musel kompletní přístup k repozitáři rozdávat lidem na potkání.
• Pokud by ses rozhodl Git modifikovat tak, aby toto podporoval (a choval se např. jako webová aplikace, která mi umožňuje poslat komentář, ale neumožňuje mi přepisovat cizí komentáře), tak to bude velká změna, kterou by ze všech úhlů pohledu dávalo smysl realizovat o vrstvu výše a jako samostatný projekt, protože Git sám o sobě je použitelný i bez toho a nedává smysl vyvíjet to ve stejném repozitáři, v nutně stejném jazyce/jazycích, distribuovat to jako jeden velký balík atd. A v neposlední řadě by takový projekt pravděpodobně mohl zrovna tak dobře integrovat i s jiným VCS než jen s Gitem, protože, jak jsem se exhaustivně pokoušel vysvětlit, Git v současnosti nic jiného než ono verzování souborů neřeší a ta „decentralizovaná synchronizace“ v Gitu, o které jsi mluvil původně, je mechanismus, který je pro tento účel zcela nepoužitelný.

Ať klidně vznikne nějaký gitd, který do netu vystaví nějaké REST API s endpointy /issues, /pullrequests apod., ale prostě by to neměla být součást Gitu jako takového. Je to fakt jako napsat, že Btrfs je nedodělek, protože neřeší kopírování souborů po síti.

Na ten zbytek jsem už i líný odpovídat, protože to jádro prostě leží tady v tomhle.

[Bystroushaak]

Na tuhle diskuzi nemám náladu. Nebudu ti to rozebírat po větách a pořád dokola opakovat, že je píčovina po souborovém systému chtít, aby řešil něco jiného než ukládání souborů, a pokud chceš třeba sychronizaci dat po síti nebo jednotnou strukturu nějakých konkrétních dat, tak to má řešit nějaká vrstva nad tím.

Git není souborový systém a ukládání souborů je pro něj relativně vedlejší věc. Například smalltalkovské systémy do něj cpou serializované objekty, které jdou z image rovnou do libgit2. Podstatná a složitá část Gitu není onanie kolem skenování souborového systému, ale řešení jakým způsobem jsou na sebe navázané změny, jak se větví, kdo je autorizoval a podepsal, jaké jsou mezitím konflikty a jak tohle všechno poslat někam do dalšího git repozitáře.

Pokud by Git zůstal v současné podobě, tj. bez síťového daemona, bez vlastního protokolu (nebo API) a uměl jen kopírovat soubory přes HTTP a SSH, tak přidání např. jednotného formátu pro issues a diskuze neodstraní důvod existence Githubu

Gitu v současné podobě do toho co popisuji já nechybí zas tak moc, a nevídím důvod proč by měl zůstat v současné podobě, to ostatně nezůstane ani tak, protože se pořád někam posouvá.

protože bys musel kompletní přístup k repozitáři rozdávat lidem na potkání.

Read only přístup na potkání, write přístup pak má mnoho různých možností. Nejjednodušší je email, ale taky můžeš implementovat nějaké push notifikace, omezený ssh přístup, ten démon, p2p synchronizaci, Rendezvous protocol, nebo deset dalších věcí. Přijde mi to jako relativně nezajímavý problém (musíš dát repozitáři nějak vědět že do něj chceš navrhnout k začlenění a on ti musí dát vědět jak) a naprosto nechápu proč jsi na tom tak zaseklý.

Pokud by ses rozhodl Git modifikovat tak, aby toto podporoval (a choval se např. jako webová aplikace, která mi umožňuje poslat komentář, ale neumožňuje mi přepisovat cizí komentáře)

Podle mě vůbec nereaguješ na to co píšu, ale na nějakou svojí vlastní představu toho co si asi představuju já. Což je sice pochopitelné, ale stále dost kontraproduktivní. Přepisování cizího komentáře je podle mého asi stejně podstatný problém, jako přepisování cizího kódu a git na to má mechanismy, od kontrolních součtů po gpg.

Ať klidně vznikne nějaký gitd, který do netu vystaví nějaké REST API s endpointy /issues, /pullrequests apod., ale prostě by to neměla být součást Gitu jako takového.

Nenapsal jsi žádný reálný důvod proč, kromě toho že se ti to konceptuálně nelíbí. A je třeba aby to bylo něco v gitu, protože jinak se to roztříští a nikdy neuchytí, ale taky nechceš aby se ti to míchalo s historií commitů.

[Bherzet]

Podle mě vůbec nereaguješ na to co píšu, ale na nějakou svojí vlastní představu toho co si asi představuju já.

Já mám úplně stejný pocit z tebe. Přijde mi, že prostě náhodně cituješ nějaké věty vytržené z kontextu a pak mi nějak oponuješ. Třeba ti napíšu, jaké problémy jsou kolem toho sdílení repozitáře pro zápis přes SSH a ty mi na to odpovíš, že Git podporuje HTTP a SSH. To je jak kdybys to ani nedočetl a už začal po větách odpovídat.

Tak mi možná zkus nějak říct, jak by sis představoval další vývoj Gitu, abys odstranil potřebu těch centralizovaných služeb jako je Github. Protože já fakt nechápu, jak si to představuješ. Tu mluvíš o nějaké decentralizované synchronizaci, tu o tom, jak to nejsložitější na Gitu je nějaké ukládání ohashovaných blobů na disku a kdo je autorizoval a podepsal, ale přitom třeba přesně ty podpisy jsou, pokud vím, jen jedna z hlaviček v tom commit souboru (podobně jako jméno, e-mail), se kterou se nikde dál nepracuje a rozhodně se podle toho nic neautorizuje. Pak utečeš od té decentralizované synchronizace s tím, že teda se to dá posílat e-mailem nebo přes nějaký P2P protokol…

Pak zase píšeš, že Git má mechanismy na to, jak někomu zabránit přepisovat cizí komentář. Uvedeš dva. Kontrolní součty, které s tím nesouvisí vůbec, protože prostě commitneš novou změnu, a GPG, kterým lze podepisovat commity, ale zase moc nechápu, jak chceš zabránit tomu, aby někdo pushnul nepodepsaný (nebo klidně podepsaný, ale jiným klíčem) commit, který změní nějaký soubor a dokud se někdo nepodívá do logu a nezkontroluje si ty podpisy, tak se na to nepřijde…

Nerozumím. Vůbec nechápu tvou představu. Nic ve zlém, ale skoro mi to přijde, jako bys jen sypal z rukávu nějaké buzzwordy, které se kolem Gitu sice vyskytují (decentralizace, kontrolní součty, GPG, …), ale přitom úplně ignoroval kontext, v jakém se v tom Gitu v současnosti používají.

PS: Spadl mi bouncer a musím přemigrovat server, tak proto teď nejsem na IRC. Kdyžtak to můžem probrat ještě potom tam, protože mně přijde, že se fakt úplně míjíme a nevím přesně proč. Buď ty Git totálně přeceňuješ, a nebo já nevidím nějaký enormní potenciál v těch jeho strukturách na disku nebo čem že…

[korooptev]

laom, to je tak když se někdo v noci nabumbá a hádá se sám ze sebou

[Bystroushaak]

Já mám úplně stejný pocit z tebe. Přijde mi, že prostě náhodně cituješ nějaké věty vytržené z kontextu a pak mi nějak oponuješ. Třeba ti napíšu, jaké problémy jsou kolem toho sdílení repozitáře pro zápis přes SSH a ty mi na to odpovíš, že Git podporuje HTTP a SSH.

...

Pak utečeš od té decentralizované synchronizace s tím, že teda se to dá posílat e-mailem nebo přes nějaký P2P protokol…

Já tohle prostě nepovažuji za podstatnou otázku, nevidím v tom problém a ve výsledku mě to prostě ani nezajímá. Git má několik možností jak synchronizovat data, byly tu rozebrány už asi třikrát a nevídím důvod, proč by se to v případě potřeby nemohlo rozšířit o další možnost, nebo do nějaké z již existujících dodělat funkcionalitu. Možná se prostě neshodnem protože ty v tom ten problém vidíš a přijde ti to jako přehnaná věc, která by „v gitu“ být neměla, i když jak jsem demonstroval, je toho tam docela dost už teď.

Příklad decentralizovanosti z minulého měsíce, kdy jsme si třeba s kolegy z rumunské části firmy posílali zazipovaný git repozitář po MS Teams (nechť je proklat), protože neměli přístupy ani do firemního bitbucketu, ani do firemní jiry (rumunská část se teprve nějak začleňuje do struktur firmy) a ještě navíc používají windows. A i když to mělo k ideálnímu nasazení daleko, tak to fungovalo v pohodě. Určitě by taky ocenili, kdyby tam měli všechny relevantní metadata, což neměli.

Samozřejmě v ideálním světě bys na to měl nějaký jiný mechanismus, ale to už jsi psal a já s tím souhlasil.

To je jak kdybys to ani nedočetl a už začal po větách odpovídat.

Je dost možné, že jsem to dělal. Mám teď dost rozesrané spaní a psal jsem to ve chvíli, kdy už jsem byl hodně unavený.

přitom třeba přesně ty podpisy jsou, pokud vím, jen jedna z hlaviček v tom commit souboru (podobně jako jméno, e-mail), se kterou se nikde dál nepracuje a rozhodně se podle toho nic neautorizuje.

Commity můžeš podepisovat pomocí GPG a pak zkontrolovat jestli podpis sedí. Když nesedí, tak víš že bylo s historií / obsahem manipulováno a prostě takové změny nepřijmeš. Úplně stejný mechanismus můžeš použít pro diskuzní příspěvky, wiki a další.

jak chceš zabránit tomu, aby někdo pushnul nepodepsaný (nebo klidně podepsaný, ale jiným klíčem) commit, který změní nějaký soubor a dokud se někdo nepodívá do logu a nezkontroluje si ty podpisy, tak se na to nepřijde…

Prostě tam přidáš ověření podpisu a změny, které mají neplatný podpis odmítneš. Změny bez podpisu bezpečné nebudou.

nebo já nevidím nějaký enormní potenciál v těch jeho strukturách na disku nebo čem že…

Nejde o struktury na disku, ale o „protokol“ vytváření blockchainu, který jde použít i k dalším věcem, než na sebe jen vrstvit commity. Ten samý protokol přímo můžeš použít pro další funkcionalitu. Tohle je ta podstatná věc na gitu, ne nějaké commandline utility, nebo další fluff kolem, to mají všechny ostatní VCS taky, včetně SVN.

[xkucf03]

Commity můžeš podepisovat pomocí GPG a pak zkontrolovat jestli podpis sedí. Když nesedí, tak víš že bylo s historií / obsahem manipulováno a prostě takové změny nepřijmeš. Úplně stejný mechanismus můžeš použít pro diskuzní příspěvky, wiki a další.

Když se tu často mluví o té „sociální“ stránce věci, tak tady bych právě čekal, že budeš mít nějakou federaci identit¹ a uživatelé/vývojáři budou mít nějaké své profilové stránky, kde se o nich budeš moci něco dočíst, podívat se na jejich historii (např. tam vystaví, do čeho přispívali, jaké chyby kde nahlásili atd.).

Veřejné GPG klíče budou třeba součást těch profilů… Ale tady právě musíš vymyslet ten protokol na vyhledávání těch domovských serverů, profilů uživatelů, importování klíčů atd. Tohle je právě ten podstatný objem práce a to, o čem mluvím, když mluvím o decentralizovaných a federalizovaných systémech pro vývojáře.

Tzn. ten Git, který by při pokusu o vložení komentáře kontroloval GPG podpis je jen malý dílek skládačky kdesi uvnitř/vespod – ale nejdřív se do něj musí nějak dostat ty veřejné GPG klíče oprávněných uživatelů a tyto klíče musíš nejdřív někde najít a spojit si je s lidmi, kterým věříš.

Přijde mi, že v té úvaze předjímáš nějaké konkrétní technické řešení (1. bude to právě v Gitu, 2. bude to všechno v jednom repozitáři, 3. nebudou to běžné soubory, ale nějaký alternativní strom). Mně přijde lepší k té analýze a návrhu přistupovat z druhé strany, trochu poodstoupit, podívat se víc zdálky a zamyslet se nad tou architekturou a nebýt utopený v technických detailech… A tomu ještě předchází nějaká ekonomická úvaha, jestli se do toho chceme pouštět a jestli je to v našich silách, nebo jestli to má být jen planá diskuse (pak je tedy úplně jedno, z které strany se začne, protože výsledek bude vždy stejný).

_{[1] mám zkušenost se SAML/Shibboleth, ale dá se to realizovat i jinak}

[Bystroushaak]

Veřejné GPG klíče budou třeba součást těch profilů… Ale tady právě musíš vymyslet ten protokol na vyhledávání těch domovských serverů, profilů uživatelů, importování klíčů atd. Tohle je právě ten podstatný objem práce a to, o čem mluvím, když mluvím o decentralizovaných a federalizovaných systémech pro vývojáře.

Tohle uznávám, a tuhle část problému skutečně začlenění metadat do repozitáře neřeší. Různé federalizované „forge“ tohle asi můžou řešit.

Veřejné GPG klíče budou třeba součást těch profilů…

Ty klíče můžeš udělat součástí stromu metadat, s tím že když je třeba přejít na nový, tak prostě tím starým podepíšeš ten nový. Ideálně by to samozřejmě chtělo nějak automaticky integrovat.

nejdřív se do něj musí nějak dostat ty veřejné GPG klíče oprávněných uživatelů a tyto klíče musíš nejdřív někde najít a spojit si je s lidmi, kterým věříš.

To může být navázané na schvalování lidí, kterým věříš s přispíváním kódu. Pokud ti teďkon jako Bystroushaak můžu poslat pull request na githubu, nebo gitee, nebo čem vlastně, tak je to stejné, jako kdybych ti poslal pull request v gitu s metadaty a přidal k tomu svůj veřejný klíč, který by se integroval do metadat jako schválený klíč. Tedy úplně stejně nemáš tušení kdo vlastně jsem, jen že mám někde nějaký účet a u něj nějaká metadata.

Původně tu Bherzet zmiňoval jak zabránit přepisování historie komentářů v těch metadatech, tak jsem to navrhoval jako očividný způsob. Pokud chceš řešit prokazování identity, tak to je samozřejmě o řád složitější problém.

Přijde mi, že v té úvaze předjímáš nějaké konkrétní technické řešení (1. bude to právě v Gitu, 2. bude to všechno v jednom repozitáři, 3. nebudou to běžné soubory, ale nějaký alternativní strom). Mně přijde lepší k té analýze a návrhu přistupovat z druhé strany, trochu poodstoupit, podívat se víc zdálky a zamyslet se nad tou architekturou a nebýt utopený v technických detailech… A tomu ještě předchází nějaká ekonomická úvaha, jestli se do toho chceme pouštět a jestli je to v našich silách, nebo jestli to má být jen planá diskuse (pak je tedy úplně jedno, z které strany se začne, protože výsledek bude vždy stejný).

Za mě je to rozhodně jen planá diskuze, mám toho dost pracovně i osobně, než abych se pouštěl do něčeho takového. Ale planá diskuze neznamená, že nemůže být zároveň zajímavá.

[Bherzet]

Původně tu Bherzet zmiňoval jak zabránit přepisování historie komentářů v těch metadatech

Ne, ne, ne. Mně nešlo o historii v Gitu, tam tomu samozřejmě zabráníš těmi podpisy, ale o to, že Git ti nezabrání přidat další commit a ten aktuální stav prostě změnit. Tzn. že bys musel nějak řešit autorství objektů/souborů s tím, že nikdo jiný je měnit nemůže.

Asi by to šlo řešit nějakým pre-commit hookem, který nad již existujícími soubory, které přicházejícím commitem modifikuješ, udělá blame, zjistí, kdo je podepsal, a změnu akceptuje pouze a jen v případě, že se jedná o jejich původního autora (a nebo případně někoho z white-listu – moderátorů), což by ověřil právě podle toho podpisu.

Nicméně celá tahle diskuze se odvinula od výroku, že Git je nedodělek, takže předpokládám, že tenhle hack nepovažuješ za dostatečný.

[Bystroushaak]

Ne, ne, ne. Mně nešlo o historii v Gitu, tam tomu samozřejmě zabráníš těmi podpisy, ale o to, že Git ti nezabrání přidat další commit a ten aktuální stav prostě změnit. Tzn. že bys musel nějak řešit autorství objektů/souborů s tím, že nikdo jiný je měnit nemůže.

To ano, ale tím to změníš lokálně pro sebe, což ti při pokusu o sjednocení s dalším repozitářem bude odmítnuto, protože nebudou sedět hashe / podpisy.

Asi by to šlo řešit nějakým pre-commit hookem, který nad již existujícími soubory, které přicházejícím commitem modifikuješ, udělá blame, zjistí, kdo je podepsal, a změnu akceptuje pouze a jen v případě, že se jedná o jejich původního autora (a nebo případně někoho z white-listu – moderátorů), což by ověřil právě podle toho podpisu.

Ano, to je jedna možnost, druhá je prostě rozšířit specifikaci tak, že na tohle bude dohlížet v metadatových stromech, které budou mít tenhle příznak.

Nicméně celá tahle diskuze se odvinula od výroku, že Git je nedodělek, takže předpokládám, že tenhle hack nepovažuješ za dostatečný.

Lol. A tu poznámku k tomu jsi taky četl, nebo jsi byl triggered jen na základě jedné věty?

[Bherzet]

To ano, ale tím to změníš lokálně pro sebe, což ti při pokusu o sjednocení s dalším repozitářem bude odmítnuto, protože nebudou sedět hashe / podpisy.

Wut?

Lol. A tu poznámku k tomu jsi taky četl, nebo jsi byl triggered jen na základě jedné věty?

Četl a neřekl bych, že jsem triggered. Prostě nesouhlasím s tím názorem, že Git je v tomhle směru nedodělek.

[Bherzet]

Příklad decentralizovanosti z minulého měsíce, kdy jsme si třeba s kolegy z rumunské části firmy posílali zazipovaný git repozitář (..)

Jenže Github je přece tak populární právě proto, že posílat si repozitáře, patche nebo bug reporty e-mailem nebo přes různé self-hosted weby (které často vyžadují registraci) lidi nechtějí. V dřívějších diskuzích o Githubu přesně tyto argumenty zaznívaly.

Proto jsem předpokládal, že když jsi mluvil o decentralizované synchronizaci a o tom, že když Git přímo nějak nestandardizuje to ukládání projektových metadat, tak to chceš všechno řešit prostě nějakým „untrusted“ pushem. A to by bylo technicky fakt strašně složité do Gitu našroubovat a ani si nejsem jistý, že by to lidi ocenili víc než webové klikátko typu Gitea (když už stejně někde musí mít VPS a na té si něco hostovat).

Commity můžeš podepisovat pomocí GPG a pak zkontrolovat jestli podpis sedí. Když nesedí, tak víš že bylo s historií / obsahem manipulováno a prostě takové změny nepřijmeš. Úplně stejný mechanismus můžeš použít pro diskuzní příspěvky, wiki a další.

Jo, ale to právě nic neřeší. Umožňuje ti to ověřit autenticitu nějakého commitu. To dává smysl právě ve chvílích jako je tato, kdy lidé masivně mirrorují nějaký repozitář a je třeba ověřit jeho legitimitu.

Ale neřeší to tu samotnou distribuci změn. Ty máš u sebe jednu kopii repozitáře, random weirdo on the Internet má taky svůj repozitář a chce ti poslat svých pár commitů. Na Githubu by vytvořil pull-request. Ale bez Githubu? Samozřejmě si může svůj repozitář taky zpřístupnit po síti a poslat ti jeho URL e-mailem, ale to může udělat už teď a to se ti právě nelíbí, protože Git je prý nedodělek a kvůli tomu vznikají ty služby typu Github.

Prostě tam přidáš ověření podpisu a změny, které mají neplatný podpis odmítneš. Změny bez podpisu bezpečné nebudou.

To neodpovídá na můj dotaz.

Nejde o struktury na disku, ale o „protokol“ vytváření blockchainu, který jde použít i k dalším věcem, než na sebe jen vrstvit commity.

Blockchain, the amazing solution for almost nothing

[Bystroushaak]

Jenže Github je přece tak populární právě proto, že posílat si repozitáře, patche nebo bug reporty e-mailem nebo přes různé self-hosted weby (které často vyžadují registraci) lidi nechtějí. V dřívějších diskuzích o Githubu přesně tyto argumenty zaznívaly.

Proto jsem předpokládal, že když jsi mluvil o decentralizované synchronizaci a o tom, že když Git přímo nějak nestandardizuje to ukládání projektových metadat, tak to chceš všechno řešit prostě nějakým „untrusted“ pushem. A to by bylo technicky fakt strašně složité do Gitu našroubovat a ani si nejsem jistý, že by to lidi ocenili víc než webové klikátko typu Gitea (když už stejně někde musí mít VPS a na té si něco hostovat).

Uznávám validitu tohohle argumentu a je pravda, že tohle jsem v téhle diskuzi neřešil. Nicméně to že kritizuji nějaký aspekt něčeho neznamená, že musím dodat řešení všeho, nebo vůbec čehokoliv.

Jo, ale to právě nic neřeší. Umožňuje ti to ověřit autenticitu nějakého commitu. To dává smysl právě ve chvílích jako je tato, kdy lidé masivně mirrorují nějaký repozitář a je třeba ověřit jeho legitimitu.

Ale neřeší to tu samotnou distribuci změn. Ty máš u sebe jednu kopii repozitáře, random weirdo on the Internet má taky svůj repozitář a chce ti poslat svých pár commitů. Na Githubu by vytvořil pull-request. Ale bez Githubu? Samozřejmě si může svůj repozitář taky zpřístupnit po síti a poslat ti jeho URL e-mailem, ale to může udělat už teď a to se ti právě nelíbí, protože Git je prý nedodělek a kvůli tomu vznikají ty služby typu Github.

To co jsem tady kritizoval a už asi pětkrát opakoval je, že git neřeší distribuci metadat k projektu. Druhá věc je samozřejmě samotný mechanismus pull / merge requestu, který ano, github řeší nějak a to co jsem tu popsal by ho neřešilo, nicméně zde v diskuzi byly dány odkazy na projekty, které to částečně, nebo úplně řeší.

Blockchain, the amazing solution for almost nothing

Except for the whole world of opensource. To o čem tam mluví oni jsou finanční blockchainy.

[xkucf03]

To co jsem tady kritizoval a už asi pětkrát opakoval je, že git neřeší distribuci metadat k projektu.

Pokud půjdeme cestou nejmenšího odporu a budeme hledat řešení, které odstraní většinu problémů, byť nebude dokonalé a čisté, tak stačí:

1. Striktně trvat na tom, že používáme pouze svobodný software (tzn. místo GitHubu např. Gitlab, Gitea, Kallithea, Sourcehut, Phabricator…).
2. Děláme pravidelné zálohy – přes API toho (byť třeba centralizovaného) systému si třeba jednou za den stáhneme všechny wiki stránky, požadavky, hlášené chyby atd. Tohle budou dělat správci projektu, kteří případně upravenou verzi zálohy (bez osobních/citlivých údajů) klidně i zveřejní a poskytnou uživatelům.

Ano, musíš vždy stahovat všechno a není to elegantní řešení postavené na přírůstkových zálohách a hashových stromech, ale…

Tím naprosto primitivním způsobem dosáhneš nezávislosti na aktuálním poskytovateli služeb a na zemi/legislativě, ve které se ty aktuální servery nachází.

Tohle je výchozí bod od kterého bychom se měli odrazit. Není potřeba kvůli tomu ohýbat nebo rozšiřovat git nebo vyvíjet jiný software – stačí vzít to, co je už teď k dispozici a situace se výrazně zlepší. Pak se můžeme bavit o tom, jak mezi těmito instancemi sdílet uživatelské profily, jak nahodit federalizaci identit (třeba ten SAML, o kterém jsem tu psal), jak si automatizovat distribuci SSH a GPG klíčů atd. Ale jestli se něco zabuduje přímo dovnitř Gitu nebo ne, to je až ta úplně poslední otázka.

Přijde mi ale, že spousta programátorů ve skutečnosti nechce vyřešit nějaký problém, ale chce jen onanovat nad nějakým „dokonalým“ technickým řešením resp. jeho fragmentem a kouskem kódu…

[Bystroushaak]

Tohle je výchozí bod od kterého bychom se měli odrazit. Není potřeba kvůli tomu ohýbat nebo rozšiřovat git nebo vyvíjet jiný software – stačí vzít to, co je už teď k dispozici a situace se výrazně zlepší. Pak se můžeme bavit o tom, jak mezi těmito instancemi sdílet uživatelské profily, jak nahodit federalizaci identit (třeba ten SAML, o kterém jsem tu psal), jak si automatizovat distribuci SSH a GPG klíčů atd. Ale jestli se něco zabuduje přímo dovnitř Gitu nebo ne, to je až ta úplně poslední otázka.

Jak už jsem psal, já to řešit (momentálně) nehodlám.

Děláme pravidelné zálohy – přes API toho (byť třeba centralizovaného) systému si třeba jednou za den stáhneme všechny wiki stránky, požadavky, hlášené chyby atd. Tohle budou dělat správci projektu, kteří případně upravenou verzi zálohy (bez osobních/citlivých údajů) klidně i zveřejní a poskytnou uživatelům.

To je takové řešení neřešení, protože ano, data můžeš potom mít stažená někde externě, ale každý nástroj bude mít jiný formát a reálně bude stejně těžké s tím nějak pracovat, či to přenést někam jinam. Pokud by pro tohle existovala podpora přímo v gitu, elegantně by jsi tím vyřešil jednotný formát, samotné přenášení dat, ale i práci s tím, protože tu by si každý mohl implementovat jak chtěl a měl by nějakou záruku, že se k těm datům všichni budou chovat stejně. Například by jsi mohl s issues / wiki pracovat přímo z IDE, kdežto takhle asi moc nehrozí, že IDE bude podporovat práci s exportem z gitlabu. I kdyby náhodou ano (třeba formou nějakého doplňku), tak je ti to stejně k ničemu, protože potřebuješ ještě způsob jak to zase dostat zpět do gitlabu.

[xkucf03]

Blockchain, the amazing solution for almost nothing

Except for the whole world of opensource. To o čem tam mluví oni jsou finanční blockchainy.

Já bych tedy rozlišoval blockchain a prostý hashový strom. Blockchain, který staví na P2P sítích a na myšlence, že nemůžeš nikomu věřit (a věříš až všeobecnému konsenzu), je obrovsky neefektivní resp. výpočetně náročný. Pro firmy a banky je to většinou nevhodné řešení, protože ty nepracují v prostředí, kde nikdo nikoho nezná a nikomu nevěří – naopak většinou pracují v prostředí dost svázaném legislativou – takže ty výhody nevyužijí a akorát v tom propálí ten výpočetní výkon, naprosto zbytečně. Tohle je výhodné maximálně pro nějaký ten start-up, který je chce tímto buzzwordem oblbovat a dodávat jim ho.

Oproti tomu ten obyčejný hashový strom je nenáročná technologie, která může věci naopak dost zefektivnit. A i když do jednotlivých uzlů toho stromu budeš vkládat třeba GPG podpisy, tak je to pořád dost nenáročné.

[Bystroushaak]

To co je náročné na finančních blockchainech je mechanismus konsenzu, který je v gitu přesunut na toho kdo dělá pull request.

Imho je to co se v gitu používá stále blockchain, i když konsenzus neřeší, protože ty stromy tvoří blockchain, tedy na sebe navazující bloky s hashi zaručujícími konzistenci. Pokud to lidi tak triggeruje, tak ten výraz můžu přestat používat.

[Josef Kufner]

na toho kdo dělá pull request.

Přijímá.

Ale jinak souhlasím, Git je/používá blockchain.

[Bystroushaak]

Přijímá

Díky, tak jsem to myslel.

[Bherzet]

Except for the whole world of opensource. To o čem tam mluví oni jsou finanční blockchainy.

Kdyby Git nepoužíval blockchain, ale prostě měl interně uložené zazipované archivy s celými pracovními stromy a nad nimi pak příšerně neefektivně dělal diffy, na této diskuzi se vůbec nic nezmění. Nebylo by o nic těžší vyřešit ukládání projektových metadat, vyřešit výměnu dat mezi repozitáři prostřednictvím nějaké P2P sítě nebo kdesi cosi.

Ty jsi se vyjadřoval ve smyslu jako kdyby skutečnost, že Git používá blockchain a umožňuje podepisovat commity, nějak významně usnadňovala případnou implementaci nějaké patrně totálně decentralizované sítě, která by odstranila potřebu těch centralizovaných služeb jako je Github, ale tak to prostě není.

Je to jako s tím souborovým systémem. Taky bych mohl tvrdit, že Btrfs je nedodělek, protože neumožňuje decentralizovaně vyměňovat data po síti. A pak bych mohl začít v diskuzi fabulovat s nějakými výroky, že to složité na Btrfs přece jsou ty stromy, žurnálování a kontrola integrity dat. Určitě to musí být nějak užitečné pro postavení intergalaktického decentralizovaného úložiště, right?

[Bystroushaak]

Yeah, sure, whatever. Co jsem chtěl jsem napsal, pokud se ti to pořád zdá jako blbost, tak se prostě neshodneme v názorech. Možná se k tomu může vyjádřit ještě někdo další? Nemám problém přijmout konsenzus, akorát mi k tomu nestačí jeden proti-názor.

[Bherzet]

Ono jsme totiž zaběhli do zbytečných technikálií.

Ty si myslíš, že by Git nějak měl řešit ty uvedené věci. OK. To si myslet klidně můžeš. Já jsem ti oponoval s tím, že podle mě to nemá řešit přímo Git, ale nějaká vrstva nad ním. Na to bys mohl třeba argumentovat, že i tohle je přece jen detail a záleží ti na tom výsledném stavu, ne na tom, jak to bude vyvíjené a distribuované. Pořád bych nesouhlasil s tím výrokem, že je Git nedodělek, ale OK, pochopili bychom se a nebylo by se o čem dál přít.

Ale místo toho jsme zabředli do technikálií v Gitu (blockchain, podepisování commitů atd.) a tam ti prostě nemůžu neoponovat, protože podle mě tyhle věci nijak neusnadňují dosažení toho tvého cíle.

[Bystroushaak]

Podle mě jsi až moc zaseklý nad tím mým prohlášením, že mi git přijde jako nedodělek. Pro mě to prohlášení neznamenalo nic podstatného a ty to už omíláš v několikátém komentáři, jak kdybych ti šlápnul na nějakou modlu, nebo něco. Pokud ti to tak vadí, tak beru to prohlášení zpět.

[Bherzet]

Nic neznamenalo, ale rozepsal jsi to do celého komentáře o tom, proč ti to jako nedodělek přijde a v čem. Já vyjádřil názor, že by se to mělo řešit o vrstvu výše. Na to ses se mnou cca někde v #76 začal hádat ve smyslu, že Git už vlastně všechny ty složité věci řeší a bylo by snadné to tam přidat, což prostě není pravda. A to je ve skutečnosti to, o čem se většinu téhle diskuze dohadujeme.

Tu diskuzi můžeme uzavřít s tím, že by se nám líbilo, kdyby v ekosystému okolo Gitu existoval nějaký způsob, jak spolupracovat bez centralizovaných služeb jako je Github. Taky se shodneme na tom, že by bylo fajn, kdyby i issue tracker byl v Gitu (ať už ve stejném, nebo v odděleném repozitáři) – aby se, jak podotkli ostatní, v případě mirrorování projektu nemuselo pro stahování issues používat jiné API atd.

V čem se neshodneme je, jestli to má spolu s tou komunikací řešit přímo Git (myslíš si ty), nebo vrstva nad ním (myslím si já). Vzhledem k tomu, že se to nikdo z nás programovat nechystá, to ale není zas tak klíčové a nemá smysl se o tom dál dohadovat.

Zásadně ale nesouhlasím s tím, že by bylo snadné Git překopat tak, aby zmizel důvod existence Githubu. Bylo by to nesmírně obtížné a s velkou pravděpodobností by drtívá většina řešených problémů vůbec nijak nesouvisela konkrétně s Gitem jako takovým a jeho konkrétní implementační detaily (blockchain, podepisování commitů, …) by bylo možné použít v míře jen velmi omezené.

[kralyk z abclinuxu]

Mně to celkem dává smysl ty rozšíření gitu, pokud by se udělaly nějak slušně. Asi by se to dalo nějak nahackovat nad gitem, tak, jak je, případně, kdyby to mělo být čistší řešení, asi by to chtělo přidat podporu nějakýho dalšího objektu k té základní sadě (blob, tree, commit, tag). Např. message, která by abstrahovala issue, komentář, pull request apod.

Otázka, jestli git je/není "nedodělek" mi přijde jen jako sémantika. IMO git není nedodělek v tomu smyslu, že to co dělá, dělá dobře. Nedodělek to je v tom smyslu, že to vůbec nestačí na kolaboraci skupiny lidí, na to člověk potřebuje víc a git aktuálně dodává jen část potřebný funkcionality. To prostě tak je.

[Bystroushaak]

Např. message, která by abstrahovala issue, komentář, pull request apod.

Jo, to by asi bylo čistější.

Otázka, jestli git je/není "nedodělek" mi přijde jen jako sémantika. IMO git není nedodělek v tomu smyslu, že to co dělá, dělá dobře. Nedodělek to je v tom smyslu, že to vůbec nestačí na kolaboraci skupiny lidí, na to člověk potřebuje víc a git aktuálně dodává jen část potřebný funkcionality. To prostě tak je.

Ano, tak jsem to +- myslel.

[Bystroushaak]

Přemýšlel jsem, a abych jen nereagoval na to co píšeš formou krátkých odpovědí:

Myslím že neporozumění mezi námi se zakládá na tom, že předpokládáš, že mluvím o gitu jako o commandline utilitě, kterou asi používáš, přestože jsem několikrát psal výrazy jako „git protokol“.

Git je samozřejmě tak commandline utilita, ale ta pouze implementuje nějaký protokol, jak nakládat s nějakým druhem dat. Stejně tak jako je thunderbird program implementující mimo jiné SMTP protokol, nebo spíš lépe, jako je sqlite databáze, a zároveň popis a referenční implementace datového formátu té databáze.

To je první miskoncepce (nemluvím o programu, ale o specifikaci). Druhá je, že git je jednoduchý monolitický program, který dělá jednu věc. Pokud jsi někdy viděl distribuci gitu (odkazoval jsem jí v minulém komentáři), tak git je složený z mnoha utilit, je to netriviální systém programů, který dělá mnoho věcí, včetně implementace imap protokolu a posílání emailů, podpory ssl, grafického klienta (gitk, git gui) a tak dál.

Když mluvím o „gitu jako protokolu“, nemyslím tím protokol přenosu dat mezi dvěma git repozitáři, ale o specifikaci dané referenční implementací, která říká jak na sebe navazují jednotlivé commity formou blockchainů, jak fungují větve, jaké metadata jsou kde a jaké je očekávané chování.

Existuje mnoho implementací téhle specifikace, viz třeba ta libgit2, nebo Dulwich. Git jako program, tedy commandline utilita, je referenční implementace.

Když jsem v tomhle threadu kritizoval git, nekritizoval jsem commandline utilitu, nýbrž protokol, respektive jeho (možná záměrnému) vyhýbání se sociální části distribuované správy kódů.

Rozšíření protokolu o specifikace metadat separátního blockchainu, který nazvu metadaty, nebrání technické překážky. Taky to nijak nenarušuje tvůj život s commandline wrapperem git. Tento separátní protokol by mohly používat lokální klienti, například v tvém IDE, samostatné grafické aplikace, nebo i giganti jako github, gitlab a bitbucket, aby ukládaly a načítaly separátní metadata přímo z repozitáře, místo aby to měly někde separátně v databázi zamknuté ve svém systému.

Pak je zde ještě otázka distribuce merge/pull requestů, resp. dat a metadata mezi dvěma repozitáři, ale to má mnoho různých řešení, včetně například emailu, nebo nějaké pseudo-centrální serverové části, jak jsi sám psal. O to mi v mé kritice ani moc nešlo, protože to považuji za poměrně uspokojivé už dnes.

[Bherzet]

To, jak si Git organizuje metadata na disku, mi přijde jako technický detail. Myslím si, že by dávalo větší smysl ty komentáře ukládat prostě jako soubory a ty pak celé verzovat Gitem (pokud by to prvně někde procházelo schvalovacím procesem, aby se zabránilo floodingu a zabordelení repozitáře) než to ukládat v nějakých jeho interních strukturách, jestli myslíš tohle, ale budiž.

Jenže jak říkám: ten zakopaný pes není v nějakém schématu, v jakém ukládat další informace o projektu, ale v té výměně dat. Ty jsi psal o té decentralizované synchronizaci jako kdyby to už Git nějak řešil, ale přitom to je právě ta jedna věc, kterou v podstatě neřeší. U Gitu se občas mluví o decentralizaci v tom smyslu, že každý má svou kopii repozitáře, se kterou si může libovolně nakládat, ale ten klíčový střípek mozaiky – výměnu dat mezi vzájemně si nedůvěřujícími stranami – neřeší.

Kdybys napsal, že ti pro Git chybí (i.) nějaký standard, jak ukládat metadata o projektu a (ii.) nástroj, který by umožňoval tu komunikaci, tak se nemáme o čem bavit, protože mi to chybí taky. Jenže ty jsi to všechno smíchal dohromady a navíc napsal, že Git je nedodělek, což je přecejen sémanticky někde trochu jinde.

Samozřejmě by bylo fajn, kdyby i z Githubu šlo vycheckoutovat repozitář se zdrojákem a pak třeba nějak separátně repozitář s veškerými issues. Stejně tak by byl fajn ten nástroj, který umožňuje si bezpečně vyměňovat data – a vůbec k tomu nepotřebovat tu službu jako je Github.

Mimochodem si všimni, že ten problém je poměrně dost dobře zobecnitelný. Kdybys chtěl na svém skoro-statickém webu komentáře, potřeboval bys k tomu nějaký endpoint, do jehož chřtánu můžeš nasměrovat nějaký HTML formulář. Tam by sis pak nakonfiguroval, co to má s těmi daty udělat: např. je uložit do souboru {page}/comments/{YYYYmmdd}_{id}.md a triggernout skript na přerenderování. Řešil bys tam identické problémy, jaké nevyhnutelně budeš řešit i u toho Gitu: ochranu proti robotům a spamu, blacklistování apod. Samotný obsah zprávy – jestli je to komentář, bug report nebo URL repozitáře, ze kterého lze stáhnout další commity (pull-request) – na tom nic nemění.

Proto si fakt myslím, že s Gitem to nemá až tak moc společného. Možná kromě té první části, tj. víceméně struktury projektu (podobně jako se s příchodem Githubu uchytilo README.md), ale ta sama o sobě tu závislost na centralizovaných službách neodstraní. Je to o té mnohem zapeklitější síťové části a odtud tedy moje skeptické reakce.

[Martin Mareš]

Užitečné by to asi bylo, ale zjevně to ostatním nepřijde tak zajímavé, aby se do toho pustili. Máte možnost být první: místo kritizování Gitu, že to neumí, ho to naučit Pokud to bude vážně tak dobré, jak říkáte, jistě se to maintainerům bude líbit.

[xkucf03]

taky nechceš aby se ti to míchalo s historií commitů. … Rozšíření protokolu o specifikace metadat separátního blockchainu

V principu bys měl tedy dva hashové stromy v jednom repozitáři? Jaký to má přínos a jak se to liší od situace, kdy si udělám dva repozitáře a jeden budu používat pro zdrojáky a druhý pro wiki nebo správu chyb a požadavků? Ostatně tohle rozdělení se často používá už dnes – např. dáš zvlášť sadu testů nebo specifikaci – prostě proto, že těch implementací může být časem víc a budeš proti nim chtít pouštět stejnou sadu testů nebo je psát na základě stejné specifikace.

Jinak neříkám, že je to ideální, ale jedna výhoda toho, že máš vše v jednom hashovém stromu, je v tom, že máš jednotnou historii a vždy se pohybuješ jen po uzlech toho jednoho stromu, je to dokonale jednoznačné a konzistentní. Nevýhoda je v tom, že z toho těžko vykostíš něco, co tam mít nechceš – jakmile se jednou něco stane součástí historie/stromu, tak je to tam navěky. Další nevýhoda je v tom, že všichni mají přístup ke všemu (minimálně pro čtení). U veřejných projektů svobodného softwaru to nemusí moc vadit, ale i tam máš třeba bezpečnostní chyby, které chceš po nějakou dobu držet v tajnosti.

Podle mého se nikdy nevyhneš nějaké bráně/rozhraní, která před to bude postavená – a teprve až někdo rozhodne, tak se daná věc stane součástí hashového stromu a bude se tím protokolem distribuovat dál. A pak jsou tu otázky jako:

• Mít zdrojáky i ty další věci v jednom stromu?
• Mít v jednom repozitáři více stromů nebo mít více repozitářů?
• Má smysl se vůbec vázat na konkrétní VCS nebo to udělat jako nezávislou nadstavbu, která může fungovat nad různými VCS?
• Má smysl ohýbat Git (a zrovna Git) nebo je lepší vytvořit něco úplně nového?
• Když už chceš jít tímhle směrem, tak proč nepoužít rovnou ten Fossil?
• Pokud už tedy má dojít k nějaké revoluci, tak je začlenění wiki a bugzilly vše co potřebujeme? Nemá pak smysl předělat i jiné věci a nebo přidat něco dalšího?

Např. pokud někdo zaútočí na infrastrukturu projektu nebo jeho vedení, tak vše, co prošlo tou bránou, je zaznamenané ve stromu a rozdistribuované mezi vývojáře případně i uživatele, takže pak není problém pokračovat v činnosti někde jinde. Neztratilo se nic, kromě pár potenciálních spamů, které čekaly na schválení/smazání. Pokud u té brány čekal nějaký hodnotný obsah, tak ho jistě jeho odesílatel bude mít u sebe a pošle ho znovu, jakmile projekt ožije na nějakém novém místě.

Pak je tu ještě jeden verzovací systém: Monotone, který je zajímavý tím, že se v něm všechno kryptograficky podepisuje.

Obecně mi přijde škoda, že si spousta lidí dala rovnítko mezi verzovací systém a Git a spousta zajímavých myšlenek a konceptů upadla v zapomnění nebo byla prostě ignorována, protože v módě byl Git a kdo negitoval, jako by nebyl. Řada věcí je lépe řešena i v Mercurialu, ale opět je tu stejný problém, že spousta lidí cokoli jiného než Git prostě ignoruje a nevidí nebo nechce vidět.

[Josef Kufner]

Otázka ani moc není, zda to nacpat do jednoho repozitáře, nebo do více repozitářů. Pointa je v tom, aby to v nějakém repozitáři vůbec bylo.

Dnes je běžné, že zdrojáky jsou v jednom Git repozitáři, wiki (dokumentace) v druhém a issues s merge requesty jsou kdo ví kde. A to třetí je ten problém.

Pokud by issues byly v Git repozitáři (ať už samostatném či jinak), tak to půjde mirrorovat, klonovat, migrovat a podobně. Teď to je schované v nějaké databázi a změna poskytovatele webového klikátka znamená ztrátu projektu, nebo komplikovanou migraci.

Ten Fossil toto zdá se řeší, ale lepší by bylo, kdyby to nebylo integrované přímo do jednoho VCS, ale stálo to samostatně. A rozhodně by to mělo fungovat na čistém Gitu, který používá většina světa, přičemž ten koncept může být přenositelný i na jiné VCS.

Co třeba vzít Gitea a změnit mu úložiště issues z databáze na Git repozitář? Takový prototyp by šel udělat za pár večerů...

[kralyk z abclinuxu]

V principu bys měl tedy dva hashové stromy v jednom repozitáři?

Technická: Git tohle umí, můžeš mít libovolný počet stromů, pokud si to tak uděláš. Na jednom projektu jsem to dokonce i použil (squashnul jsem silně experimentální historii a vypublikoval to squashnuté, ale pro archivační účely jsem si tam ten původní strom taky nechal paralelně, samozřejmě ten není nikam pushnutý, jen lokálně).

Obecně mi přijde škoda, že si spousta lidí dala rovnítko mezi verzovací systém a Git a spousta zajímavých myšlenek a konceptů upadla v zapomnění nebo byla prostě ignorována, protože v módě byl Git a kdo negitoval, jako by nebyl. Řada věcí je lépe řešena i v Mercurialu, ale opět je tu stejný problém, že spousta lidí cokoli jiného než Git prostě ignoruje a nevidí nebo nechce vidět.

S tím celkem souhlasim, třeba Darcs nebo Fossil jsou opravdu zajímavé. V čem je zajímavý Mercurial, to moc nevidim, mi přijde, že je prostě akorát chudší, pomalejší, méně flexibilní bratranec gitu...

[Bherzet]

Řada věcí je lépe řešena i v Mercurialu, ale opět je tu stejný problém, že spousta lidí cokoli jiného než Git prostě ignoruje a nevidí nebo nechce vidět.

Jaké třeba? Mercurial neznám. Já se prvně kdysi setkal s SVN, kterou jsme používali fakt jen k lineárnímu zaznamenávání historie změn. Pak jsem se naučil Git a po prvních neintuitivních zmatených krůčcích jsem si na něj docela rychle přivykl a asi se nedá říct, že by mi v něm něco chybělo.

A ani s tou neintuitivitou by to nebylo tak strašné, kdybych se ho nezačal pořádně učit až na ostrém projektu metodou pokus/omyl :) Ale mám pocit, že o své změny jsem snad ani nikdy nepřišel – ono stačí ten repozitář prvně někam překopírovat a až pak se pouštět do té větší magie, že. Dnes mi přijde, že kdybych někoho měl rychle zaškolit do Gitu, tak by mi to moc práce nedalo. Ale možná to podceňuju.

[xkucf03]

Já se prvně kdysi setkal s SVN, kterou jsme používali fakt jen k lineárnímu zaznamenávání historie změn.

Subversion se nemusí používat jen k lineárnímu vývoji, běžně se tam pracuje ve větvích a setkal jsem se i s týmy, kde nad tím měli postavené poměrně sofistikované procesy/postupy. Ale samozřejmě dneska už prakticky neexistuje důvod používat SVN. Hlavní problém je ta centralizovanost, není to distribuovaný systém.

Jaké třeba? Mercurial neznám.

Lepší pojetí větví (Git umí jen bookmarky, kterým říká branch; Mercurial umí jak bookmarky, tak branche), lepší pojetí historie (verzované štítky atd.), logičtější UI (CLI), možnost kopírovat (hg cp) soubory…

[kralyk z abclinuxu]

Lepší pojetí větví (Git umí jen bookmarky, kterým říká branch; Mercurial umí jak bookmarky, tak branche)

Jaká je motivace pro hg branche oproti git branchím? Přijde mi, že s git branchemi můžu dělat to samé co s hg branchemi, ale ne naopak.

možnost kopírovat (hg cp) soubory

Git technicky vzato nemá ani cp ani mv Resp. ten mv je v zásadě jen takový shorthand pro běžný filesystem move + stage těch změn.

Git kopírování a přesouvání nezaznamenává explicitně, ale detekuje to v hisorii, s tim, že si můžeš naštělovat citlivost té detekce (umí totiž zdetekovat i když jsi soubor během přesunu např. trochu změnil).

[kralyk z abclinuxu]

NVM, komentář beru zpět.

[Bherzet]

Subversion se nemusí používat jen k lineárnímu vývoji, běžně se tam pracuje ve větvích (..)

Já vím, že to SVN umí, ale nás tehdy nenapadlo to používat. Programovali jsme hru, kde je obecně podstatně těžší dodržovat různé obecné poučky, návrhové vzory a způsob organizace práce, který platí jinde, a navíc v kombinaci s tím, že to byl první serióznější projekt, na kterém jsem nepracoval sám, ale s kamarádem, a taky jsem do té doby VCS vůbec nepoužíval (používal jsem zazipované archivy :D), tak jsme to SVN používali v podstatě primárně k synchronizaci kódu mezi sebou.

Je to řadu let nazpět. Dnes se na to samozřejmě dívám úplně jinak a na tom projektu jsem se dopustil mnoha různých chyb, kvůli kterým se ho vlastně nikdy nepodařilo dotáhnout do konce, ale byla to velmi cenná „learning experience“ a na celé to období plné enthusiasmu a programování během každé volné minuty rád vzpomínám.

Git umí jen bookmarky, kterým říká branch; Mercurial umí jak bookmarky, tak branche

Aha, chápu. Tady to vysvětlují:

Git, by contrast, has "branches" that are not stored in history, which is useful for working with numerous short-lived feature branches, but makes future auditing impossible. Mercurial's bookmark feature is analogous to Git's branching scheme, but can also be used in conjunction with Mercurial's traditional named branches.

[Michal Kubeček]

Obecně mi přijde škoda, že si spousta lidí dala rovnítko mezi verzovací systém a Git a spousta zajímavých myšlenek a konceptů upadla v zapomnění nebo byla prostě ignorována, protože v módě byl Git a kdo negitoval, jako by nebyl.

To nemá nic společného s nějakou módou, to je čistě praktická záležitost. Ne každý má chuť a čas sledovat, studovat a zkoušet všechny cool programovací jazyky, build systémy, VCS, editory, …, které se kde objeví. Ono to totiž zabírá čas, který by se dal věnovat něčemu, co dotyčný považuje za užitečnější.

Takže ano, klidně se přiznám, že jsem jeden z těch "omezených", kdo se radši pořádně naučí pracovat s gitem, sledují novinky v něm, které jsou pro jejich práci užitečné (z poslední doby třeba range-diff, rebase --exec, rebase -i -r nebo --edit-description s využitím pro format-patch), protože to mi zjednoduší a zefektivní práci. Učit se dalších devět VCS, které žádný z projektů, na kterých pracuji, nepoužívá, by mi naopak ubíralo čas, který takhle můžu věnovat něčemu, co pro mne má význam. Představa, že by kernel používal jeden VCS, iproute2 druhý, ethtool třetí, firebird čtvrtý a k tomu bych ještě používal pátý (a možná šestý, sedmý a osmý) na své soukromé věci jen proto, že mají nějaké zajímavé myšlenky nebo koncepty, mne neláká ale spíš děsí.

Pro většinu vývojářů je VCS nástroj, který jim má ulehčit a zefektivnit práci. Git tuto roli plní velmi dobře a proto je tak populární. Žádný rozumný správce netriviálního projektu nebude migrovat na jiný VCS jen proto, že mu to přijde zajímavé. Pokud nějaký projekt přešel na git, bylo to proto, že to lidem, kteří o tom rozhodli, připadalo natolik užitečné, že to stálo za ty nemalé komplikace. Aby někdo z gitu přešel na jiný VCS, musel by mít stejně dobré důvody - a o tolik lepší jiné VCS prostě nejsou. No a pokud někdo zakládá nový projekt, je stejně tak logické, že první volbou je VCS, který je nejrozšířenější, nejvíc potenciálních vývojářů už ho zná a existuje pro něj spousta podpůrných nástrojů, nadstaveb a integrace do editorů a vývojových prostředí.

[Bystroushaak]

V principu bys měl tedy dva hashové stromy v jednom repozitáři? Jaký to má přínos a jak se to liší od situace, kdy si udělám dva repozitáře a jeden budu používat pro zdrojáky a druhý pro wiki nebo správu chyb a požadavků?

Přínos je samozřejmě v tom, že jedno je součást protokolu, druhé je meta-protokol, který si vymýšlíš sám a skončí to prostě tak že bude o standard víc a nikdo to nebude používat.

Když už chceš jít tímhle směrem, tak proč nepoužít rovnou ten Fossil?

Já nechci jít tímhle směrem. Něco jsem kritizoval, že mi přijde jako chybějící. Tohle je diskuze na webu na téma „přijde mi že gitu chybí reflexe sociálního aspektu vývoje“, ne diskuze na téma „bystroushaak jde přepisovat git“.

Vidíme situace, kde tu musím tahat informace z google webcache aby se někdo mohl podívat na pull request. Issue byly (v momentálním stavu, třeba to github ještě obnoví) projektu smazány, celkově máme centralizovaný github s čtyřiceti miliony uživatelů, mezi kterými jsem i já, a jsem z toho tak nějak nešťastný, tak prostě navrhuji jedno možné řešení.

Na Fossil se chci podívat a možná ho skutečně zkusím chvíli používat.

Má smysl se vůbec vázat na konkrétní VCS nebo to udělat jako nezávislou nadstavbu, která může fungovat nad různými VCS?

Má smysl ohýbat Git (a zrovna Git) nebo je lepší vytvořit něco úplně nového?

Imho má smysl ohýbat git, protože na nové věci těžko všichni masově přejdou.

Pokud už tedy má dojít k nějaké revoluci, tak je začlenění wiki a bugzilly vše co potřebujeme? Nemá pak smysl předělat i jiné věci a nebo přidat něco dalšího?

Určitě bych to napsal obecně. Prostě mít N vedlejších stromů pro různá metadata + nějaké RFC popisující jak vypadá třeba pojmenování a práce s těmi metadaty, když jde o wiki, když o issues a když o něco jiného. S tím že když se za 10 let přijde na to, že tam je třeba přidat další věc, tak se prostě rozšíří RFC, ale mechanismus už tam bude.

Obecně mi přijde škoda, že si spousta lidí dala rovnítko mezi verzovací systém a Git a spousta zajímavých myšlenek a konceptů upadla v zapomnění nebo byla prostě ignorována, protože v módě byl Git a kdo negitoval, jako by nebyl. Řada věcí je lépe řešena i v Mercurialu, ale opět je tu stejný problém, že spousta lidí cokoli jiného než Git prostě ignoruje a nevidí nebo nechce vidět.

Git momentálně dominuje světu opensource, ale i closedsource a imho je lepší se s tím vyrovnat, než zkoušet vymyslet něco lepšího, protože realisticky na to těžko většina lidí přejde, pokud to nebude fakt masivně lepší. Mercurial jsem používal v minulé firmě a bylo to ok, thg je super gui, ale jinak jsem z toho nijak odvařený nebyl a nemám tušení, kde mají být ty výhody.

[kralyk z abclinuxu]

Imho má smysl ohýbat git, protože na nové věci těžko všichni masově přejdou.

+1

Mimochodem, git už takovéhle mechanismy do jisté (velmi malé) míry obsahuje: Mrkni na git notes . Zkus třeba git notes add a následně git log --reflog ; objeví se tam tajemné commity mimo hlavní historii.

[Josef Kufner]

Git notes vypadá jako hezká předloha pro issue tracker :)

[marbu]

Vidíme situace, kde tu musím tahat informace z google webcache aby se někdo mohl podívat na pull request. Issue byly (v momentálním stavu, třeba to github ještě obnoví) projektu smazány

V projektech spravovaných na githubu kam přispívám si přidávám git remote pro každého uživatele, jehož kód mně zajímá. Např. bych tak měl remote origin (tj. upstream), marbu (můj clone) a pak několik dalších, pro každého dalšího vývojáře. Pomocí git fetch --all mi pak git stáhne do mého lokálního repa všechny commity ze všech existujících větvích.

Tento usecase, kdy jde o zálohu kódu v pull requestech, by tak šlo řešit i skriptem, co pro dané github repo projde všechny přispěvatele, a vytvoří mi pro každého remote. Ale je třeba to udělat předem, a klade to vyšší nároky na místo na disku ...

[marbu]

Určitě bych to napsal obecně. Prostě mít N vedlejších stromů pro různá metadata + nějaké RFC popisující jak vypadá třeba pojmenování a práce s těmi metadaty, když jde o wiki, když o issues a když o něco jiného. S tím že když se za 10 let přijde na to, že tam je třeba přidat další věc, tak se prostě rozšíří RFC, ale mechanismus už tam bude.

Tohle je obecně docela stará myšlenka, viz už zmiňované git notes nebo git annex:

I've just released git-annex version 3, which stops cluttering the filesystem with .git-annex directories. Instead it stores its data in a git-annex branch, which it manages entirely transparently to the user. It is essentially now using git as a distributed NOSQL database. Let's call it a databranch.

What I think takes git-annex beyond these is that it not only injects data into git, but it does it in a way that's efficient for large quantities of changing data, and it automates merging remote changes into its databranch. This is novel enough to write up how I did it, especially the latter which tends to be a weak spot in things that use git this way.

Btw dívám se, že Joey taky udržuje seznam distribuovaných bug trackerů

[Bystroushaak]

+1

[Josef Kufner]

Btw dívám se, že Joey taky udržuje seznam distribuovaných bug trackerů

To je velice zajímavý seznam. Díky.

[Bherzet]

Erratum:

V Gitu existují tři možnosti, jak vyměňovat data. Nejjednodušší je přenos přes HTTP(S), který umožňuje pouze read-only přístup a z našeho hlediska není vůbec zajímavý.

Zajímavější je přístup přes SSH. Ten se typicky používá v kombinaci s výše zmiňovaným git-shellem, který zamezuje spouštění nevyžádaných příkazů a naopak whitelistuje příkazy git-receive-pack a git-upload-pack. První jmenovaný je spuštěn uživatelem, který si přeje do repozitáře zapisovat; druhý je spuštěn uživatelem, který z repozitáře čte.

Dále existuje git daemon, který implementuje v podstatě totéž přes protokol git:// (TCP 9418). Autentizaci ale neřeší vůbec: neumožňuje nastavovat přístupová s granularitou lepší než „kdokoliv může číst“ a „kdokoliv může zapisovat“. Z hlediska objemu přenášených dat se ale jedná o nejefektivnější ze všech zmiňovaných metod.

Doslovně vzato tedy moje výroky o tom, že Git vůbec neřeší síťovou stránku věci, nejsou pravdivé. Jak programy git-receive-pack a git-upload-pack spouštěné přes SSH, tak git daemon, přenos dat mezi repozitáři samozřejmě řeší.

Na tvrzení, že Git nijak neřeší přístupová práva, ochranu před spamem a další podobné věci, ani na mém názoru, že by bylo krajně nešťastné to (přímo) do Gitu přidávat, se nic nemění.

[Josef Kufner]

Git po HTTP umí i zápis.

[Bherzet]

Jo, sorry, zapomněl jsem na smart HTTP. Tam se dá použít třeba git http-backend pod Apachem. Autentizaci lze řešit taky přes HTTP. Takže je to v podstatě identické jako přes to SSH (trochu jiný interní plumbing – git-receive-pack spouštěný přes SSH daemona vs. git http-backend volaný Apachem – ale co do možností se to příliš neliší).

[marbu]

Git řeší dobře tu úlohu, na kterou byl určen: verzovat soubory. S voláním po federativní kolaborativní platformě ve FOSS komunitě nejsi ani zdaleka osamocený a existují projekty, které se to snaží řešit (např. Gitea), ale vyčítat Gitu, že tohle všechno neimplementuje, je asi stejně relevantní jako si stěžovat, že kernel nemá vestavěnou podporu pro decentralizované sociální sítě, protože už stejně implementuje TCP/IP stack a ačkoliv je hezké, že si nad tím uživatelé můžou postavit, co chtějí, tak ve výsledku to skončí tak, že utečou na proprietární službu typu Facebook.

+1

Návrh gitu jako úzce specializovaného ale flexibilního nástroje pro distribuované verzování zdrojových kódů je právě důvod, proč je se stal tak populárním. Existuje mnoho workflow jak git používat, a to s čím později přišel github je jedním z nich. Kdyby git vznik jako nástroj kombinující verzování + hlášení bugů + kooperaci vývojářů s webovým rozhraním, nestal by se tak nikdy populární, mnoho projektů by ho nezačalo používat protože by jim do jejich stylu vývoje neseděl, a současný ekosystém nástrojů postavených nad gitem včetně samotného githubu by nevzniknul.

[kralyk z abclinuxu]

Nikdo tě nenutí provozovat servery v USA. Když např. píšu o tom, že by FSF měla na těchto věcech pracovat, tak to neznamená, že by se FSF (sídlící v USA) měla stát nějakým (centrálním) poskytovatelem těchto služeb. Znamená to, že by měla navrhovat standardy, protokoly a vytvářet ten software

To jsem psal já, tys psal, že FSF má razit ideologickou čistotu...

Proto je potřeba, aby danou technologii používalo co nejvíc lidí.

Ano, ale lidi těžko přesvědčíš, aby tu technologii používali, pokud to je náročné a/nebo nevýhodné a/nebo chybí featury a/nebo nepohodlné a/nebo hrozí právní postihy.

Znovu si přečti ten Jendův komentář o tržním chování.

Ty jako programátor máš oproti většinové veřejnosti výhodu a máš možnost to ovlivnit.

Ne, prakticky nemam. A to není nějaké házení flinty do žita, nesnažení se, lenost nebo něco podobného, jak se mi snažíš furt podsunout. To je prostě racionální zhodnocení situace. Je to asi jako kydbys mi dal čajovou lžičku a požádal mě, abych vykopal 10 kubíků hlíny. Já bych ti řekl, že to nejde, a ty by ses zlobil, že když budu jen sedět se založenýma rukama, tak se těch 10 kubíků nikdy nevykope. Což je sice svatá pravda, ale když začnu tou lžičkou kopat, tak se nevykopou úplně stejně a já akorát budu plítvat energií.

Nezlob se, ale u tebe nepozoruju, že bys cokoli ovlivnil, přijde mi, že se akorát zavřeš do nějaké víceméně izolované bubliny, kde je všechno svobodné a úžasné, ale mezitim ve světě venku se situace nijak nezlepšuje, naopak. A přijde mi, že přesně takhle nakonec skončil RMS (i předtím než byl vyloučen z čela FSF) jakož i někteří další lidi podobného ražení. Nezlob se, ale já takhle skončit nechci.

Další věc je, jak už jsem psal, že GitHub mi nevadí. To, co říkáš, tzn. že bych se měl zamyslet, co svým chováním (ne)ovlivňuju, jsem udělal, a došel jsem k tomu, že moje používání GitHubu je v pořádku. Ta platforma jednak mně osobně vyhovuje (myslim si, že to je skutečně poměrně velmi dobrý software, že i proprietární software může někdy být dobrý) a jednak si myslim, že i existence mého účtu tam je net gain pro FOSS (přispěl jsem do množství projektů).

Co se týče této zprávičky, nemám problém s GH (ti se jen řídí - a musí řídit - zákonem), ale s těmi zákony a s mechanismy, které k nim vedou.

Jazyková poznámka: nauč se prosím psát slovo oligopol, všiml jsem si toho u tebe už víckrát, píše se tam měkké i, ne y.

Díky za opravu, pokusim se si to zapamatovat. Nicméně tohle je na ol(i/y)gopolu asi opravdu až ten poslední problém. Nábádáš uživatele GitHubu, aby se zamysleli nad důsledky svého chování. Možná bys mohl udělat to samé a zamyslet se nad důsledky svých preferencí (jestli třeba k oligopolům nevedou a jestli to nemá nějaké neblahé důsledky).

[kralyk z abclinuxu]

Další věc je, jak už jsem psal, že GitHub mi nevadí.

Ještě poznámka: Není to o tom, že bych si neuvědomoval ty možný rizika. Uvědomuju si, že korporaci XY (v tomhle případě GitHub/Microsoft) může ze dne na den rupnout v kouli a můj projekt nebo něčí projekt, na kterým mi záleží, bude mít problémy. Nebo že nastane nějaký jiný problém plynoucí z proprietárnosti a centralizace GH. Já o nich vím, ale v té úvaze to prostě není dostatečně velké riziko, aby to převážilo výhody, které z toho plynou mně a projektům.

To je asi jako když vylezu z baráku na ulici - jsem si vědom rizika, že mě může přejet auto, že můžu zakopnout a rozbít si hlavu nebo že na mě spadne klavír z 5. poschodí. Ale to riziko podstoupím.

[kralyk z abclinuxu]

Ještě poznámka 2 (sorry! ):

Ale když na to i lidi jako ty rezignují a půjdou tou pohodlnější cestou, tak se těžko něco něco změní k lepšímu.

Já na to úplně nerezignuju, různé decentralizované technologie jsem zkoušel / používám. Zmiňovanej bittorrent určitě, ale zkoušel jsem i jiný. Např. jsem svého času používal Diasporu, ale vydrželo mi to jen nějakej čas, nikdo tam nebyl a události to nepodporuje dodnes (afaik).

V zásadě decentralizovanejm věcem fandim, ale nejsem z toho zdaleka tak nadšenej jako jiní, naopak jsem spíš skeptickej. Ono to totiž málokdy funguje v praxi dobře. Nejlíp funguje asi ten bittorrent. Ale i třeba tak relativně mainstream věc jako bitcoin; přijde mi, že používat to v praxi je strašnej pain. Jasně, koupit si kafe někde v Paralelní Polis je asi v pohodě, ale zkoušel jste někdo směnit netriviální množství bitcoinu, tj. v řádu aspoň desetin BTC? Přijde mi, že to je hroznej voser, zejména, pokud by si měl člověk zachovat soukromí.

Je klidně možné, že v budoucnu budou všelijaké federated věci hezky použitelné, ale aktuálně mi to přijde spíše v plenkách...

[Bystroushaak]

Jasně, koupit si kafe někde v Paralelní Polis je asi v pohodě, ale zkoušel jste někdo směnit netriviální množství bitcoinu, tj. v řádu aspoň desetin BTC?

Svého času jsem směňoval necelý bitcoin z prodeje etherea a šlo to v pohodě přes ty automaty co jsou různě po Praze, jen jsem to rozdělil do několika dvaceti-tisícových transakcí. Nechtělo to občanku, ani nic.

[kralyk z abclinuxu]

jen jsem to rozdělil do několika dvaceti-tisícových transakcí. Nechtělo to občanku, ani nic.

To je pravděpodobně nelegální:

Klient se zavazuje, že nevyužije služeb Provozovatele poskytovaných prostřednictvím sítě Bitcoinmatů, nebo poskytovaných jakoukoliv jinou cestou, k nákupu nebo prodeji virtuální měny, pokud by tyto nákupy a prodeje (...) přesáhly v období 1 kalendářního dne v součtu hodnotu 25000 Kč (...) byly rozděleny do dvou a více spolu jakkoliv souvisejících obchodů, které by vsoučtu přesáhly hodnotu 25000 Kč

[Bystroushaak]

Tady se bavíme o období několik let zpět + to afaik nebylo v jeden den. A když už tak porušení podmínek, ne nelegální (zákon imho o bitcoinech vůbec nic neříká).

[kralyk z abclinuxu]

Tady se bavíme o období několik let zpět

Aha, to mohlo být o dost jinak, AFAIK dnes to opravdu nějak daný zákonem je, i když konkrétní paragraf ti nejsem teď schopen odkázat. Byly ale v posledních letech schválený věci jako 4AMLD a 5AMLD.

[Bystroushaak]

Netýká se ten zákon toho, že transakce nad nějakou částku musí být provedeny elektronicky na účet příjemce? Ale ty částky byly tuším docela vysoké (něco jako 500k dřív a pak se to snižovalo na asi 60k?). O ničem jiném jsem neslyšel.

[Michal Kubeček]

Zákon 254/2004 Sb o omezení plateb v hotovosti, limit je 270000 Kč (pravděpodobně to má být přibližně 10000 EUR), původně to bylo 100000 Kč. Ale opravdu si netroufám říct, jestli a jak se ten zákon dá aplikovat i na platby v bitcoinech.

[Jendа]

U těchto nahardcodovaných limitů mě vždycky zarazí, co se stane při hyperinflaci. Až se Alena s JS pokusí vyřešit ekonomiku, tak si pak nebudu moct za hotovost koupit nic (protože přesáhnu tento limit), nebo sněmovna pojede 24/7 a bude patchovat zákony a přidávat tam nuly?

[Bherzet]

+1 :D

[Jendа]

Ještě jeden námět k zamyšlení: pranostiky, názvy jako „říjen“ a tak se posouvaly když země přešla na gregoriánský kalendář, nebo prostě jsou ty věci rozbité už tímhle a nikdo to neřeší, protože stejně nefungují? (ale třeba Lucie noci upije je astronomicky správně se současným kalendářem)

[Heron]

Ano, toto je jeden z důvodů, proč si nejsem schopen zapamatovat anglické názvy měsíců v roku. Přidávaly se tam další měsíce pojmenované po vládcích a ty původní pojmenované prostě pořadovým číslem se posunuly.

Takže september - 7 je devátý měsíc, october - 8 je desátý měsíc november - 9 je 11 a december - 10 - je dvanáctý měsíc.

A s tímto bordelem žijeme už 2000 let. (Juliánský, Gregoriánský potom řešil přestupné roky a správnou délku roku.)

[Bherzet]

Já si pamatuju všechny kromě June a July, které se mi neustále pletou.

[Josef Kufner]

Pranostiky se často vážou na svátky (jmeniny), takže ty se neporouchají :)

Gregoriánský kalendář byl v Čechách zaveden z pondělí 6. ledna na úterý 17. ledna 1584. Těch cca pět století celkem stačí na vytvoření nových pranostik. Navíc ten rozdíl při zavedení kalendáře byl proti astronomickému stavu cca 10 dnů.

[Jendа]

Pranostiky se často vážou na svátky (jmeniny), takže ty se neporouchají :)

No ale jmeniny jsou definované jako „Lucie - 13.12.“, a když se posune kalendář, takže 13.12. už není 8 dní před slunovratem, tak pak Lucie není 8 dní před slunovratem a přestane to fungovat, ne?

Jinak zrovna ta Lucie mě fascinuje i z jiného hlediska - změřit začátek noci není podle mě úplně triviální, realisticky kdy tam byla dostupná technika na to tohle zjistit?

Souhlasím, že 1584 je hodně daleko. Zeptám se kamaráda z Ruska jestli to nějak řešili u nich v 1917 .

[MadCatX]

https://gitee.com/mirrors/youtube-downloader

[Jendа]

Ano, kdybych měl připravený rootkit, tak taky teď udělám spoustu jakože-mirrorů.

[marbu]

Na druhou stranu tarbally s vydanými verzemi lze najít na PyPI nebo v repozitářích různých dister, takze lze minimálně ověřit stav kódu vzhledem k poslednímu git tagu. Navíc tohle repo musí mít lokálně uložené spousta lidí, což možnosti skývání rootkitu dál omezuje.

Když se podívám na to odkazované repo, vidím že tech commitů od poslední vydané verze k poslednímu commitu master větve není zas tolik:

* 416da574e (gitee/master) [ytsearch] Fix extraction (closes #26920)
* 48c5663c5 [afreecatv] Fix typo (#26970)
* 7d740e7dc [23video] Relax _VALID_URL (#26870)
* 4eda10499 [utils] Don't attempt to coerce JS strings to numbers in js_to_json (#26851)
* 605535776 [ustream] Add support for video.ibm.com (#26894)
* 1050e0d09 [iqiyi] Fix typo (#26884)
* d65d89183 [expressen] Add support for di.se (closes #26670)
* 0c92f1e96 [iprima] Improve video id extraction (#26507) (closes #26494)
* adae9e844 [README.md] Fix autonumber sequence description (refs #26686)
* c5764b3f8 [downloader/http] Properly handle missing message in SSLError (closes #26646)
* 0837992a2 [downloader/http] Fix access to not yet opened stream in retry
* b55715934 (tag: 2020.09.20) release 2020.09.20

Schovat tu backdoor by bylo asi možné, ale poměrně obtížné. Ale je fakt, že pořád by se našlo dost lidí, co by se s žádným ověřováním nenamáhali.

[marbu]

Navíc se dívám, že mají podepsané git tagy:

$ git show 2020.09.20
tag 2020.09.20
Tagger: Sergey M․ <dstftw@gmail.com>
Date:   Sun Sep 20 12:30:55 2020 +0700

Release 2020.09.20
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE7X9b9Gs7vtgchzaOLDk+DxipI20FAl9m6Q8ACgkQLDk+Dxip
I20gDhAApnr93XCCun/4qtw2qKbV/I2jTAwvgFClYWeMhwdCndJVgZYC4nEYbqFg
pMisb7V61XeHAyd2JpEuydmYC96Bw5EvABZfgIvhPQvPsIYmhjcsun3JkkDOAFsn
zcOnRp71UEvMAmx+7y5Lm3Oe/bb22xeM4XiUPkxeJ248XV2jV+YH8e3yvRHk69JE
rM7se062kKa9FMhDf72/M1kVqITPmHyeyDezo95bO11mqFf6iqM1WD2C30zKNcZQ
RGFDouZkpMCsCMr603Okv+B+USM/q0kE5jJDTqv7s3K99iEwQxYwrWTCfwTOYmPH
E/+2m1qRwgWJ3Fp39aZadYDHJ2orr5+XBPJq45sMRe4Netbeo52vwR0leVtuaWE+
luTAJP/ccNTptoNA89S/jWYB46rbZPyoL2B1bDFIiRRCtZiCM7jJZ3MSwkAWaN2m
ZmiPUIHQfyes5B060w9nbI8idkY8NEO3iCbdts84BrU27YWWtxYD/F7FgG0ZuGVm
MEt1+EhfIfhfKrVqtVRs41hmSJJLSz6j/xhFIHmLzIGXm06zbZZM9OsSoH4tt/+0
/RrfjtuTb61YjLws2oIFdJ/qwF2z5U2JxF++jwcjQ7Qwdm1MhMmN213KfIlTMmzu
odhehCCJS41dDvtP4hwhDsVFGcJ+LzW6FWoc4Pf7j/SksHiBXjE=
=uq17
-----END PGP SIGNATURE-----

commit b55715934bb7f9474f69b99e4d51cc83dee7cbef (tag: 2020.09.20)
Author: Sergey M․ <dstftw@gmail.com>
Date:   Sun Sep 20 12:30:45 2020 +0700

    release 2020.09.20

[marbu]

A vlastně i všechny commity:

$ git log -v --show-signature | head -12
commit 416da574ec0df3388f652e44f7fe71b1e3a4701f
gpg: Signature made Fri 23 Oct 2020 04:31:51 PM CEST
gpg:                using RSA key 2C393E0F18A9236D
gpg: Good signature from "Sergey M. <dstftw@gmail.com>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: ED7F 5BF4 6B3B BED8 1C87  368E 2C39 3E0F 18A9 236D
Author: Sergey M․ <dstftw@gmail.com>
Date:   Fri Oct 23 21:31:37 2020 +0700

    [ytsearch] Fix extraction (closes #26920)

Veřejné klíče lze získat a ověřit z keyserverů a nebo přes balíčky distribucí.

[xkucf03]

Historie včetně hashů z Gitu je uložená i na web.archive.org.

Jinak ale je dobré dodržovat toto doporučení:

Every released version (binary or source) must be cryptographically signed by the authors (GnuPG/OpenPGP is strongly recommended).

Veřejný klíč autor by uživatelé měli mít uložený ještě před „incidentem“ případně se dá sdělit nějakým důvěryhodným kanálem. Pak není problém vydávat nové verze i třeba v utajení – prostě se jen někde náhodou objeví balíčky opatřené tím správným podpisem.

[Bystroushaak]

Jsou už nějaké decentralizované alternativy ke githubu? A tím očividně nemyslím ke gitu, ale k té sociální části, issues, komentáře, schvalování pull requestů, notifikace a tak, to celé v jednom balení a federované s ostatními projekty?

[random]

Něco trochu takového dělá Pagure, ale úplná decentralizace to není, jen umožňují snadněji sdílet data mezi servery.

[xkucf03]

Myslíš decentralizovanou alternativu, která by dokázala emulovat toto chování a formu spolupráce? Tak to nevím.

Měl jsem poznamenaný odkaz na GitHub ohledně nezačleněné záplaty (byl to jen návrh), která umožňovala stáhnout video z ČT a která spočívala v úpravě čtyř souborů. Bohužel jsem si obsah záplaty neuložil. Dá se k tomu ještě nějak dostat? (Adresa byla https://github.com/ytdl-org/youtube-dl/pull/20964/files)

[Bystroushaak]

Někdo na lobsterech mě odkázal na https://forgefed.peers.community/, což vypadá na první pohled zajímavě, ale ještě jsem to nepročetl.

[kralyk z abclinuxu]

We hope to start getting NLNet funding, and to implement ForgeFed in an existing forge, Pagure.

To by mohlo docela zajímavý, pokud by se to podařilo...

[marbu]

Vzpomínám si, že se lidi od pagure.io nějak zapojili do práce na návrhu ForgeFed protokolu, ale nevím v jakém je to stavu.

[karel]

Posledni verze je 2020.09.20 stahujte:
https://pypi.org/project/youtube_dl/#files
https://git.svarun.dev/ytdl-org/youtube-dl
https://source.netsyms.com/Mirrors/youtube-dl

Windowsáci:
https://www.majorgeeks.com/files/details/youtube_dl.html

[mica]

Měl jsem poznamenaný odkaz na GitHub ohledně nezačleněné záplaty (byl to jen návrh), která umožňovala stáhnout video z ČT a která spočívala v úpravě čtyř souborů. Bohužel jsem si obsah záplaty neuložil. Dá se k tomu ještě nějak dostat? (Adresa byla https://github.com/ytdl-org/youtube-dl/pull/20964/files)

[Bystroushaak]

https://webcache.googleusercontent.com/search?q=cache:7olXd6u77pIJ:https://github.com/ytdl-org/youtube-dl/pull/20964/files+&cd=1&hl=en&ct=clnk&gl=cz

[mica]

Díky.

[Bystroushaak]

Radši si to stáhni, pokud to fakt potřebuješ, v té cache to většinou nějak podstatně dlouho nevydrží.

[Bherzet]

Příloha:

• podpora_ceske_televize_pro_ytdl.png (336999 bytů)

^

[Zond]

A řeď mi řekněte, dalo by se v Česku použití tohoto programu kriminalizovat? DMCA tu sice nemáme, ale máme tu paragraf trestního zákona o "Neoprávněném přístupu k počítačovému systému a nosiči informací", který by se na tohle dal vztáhnout.

[petr_p]

„Neoprávněný přístup“ se na to napasovat nedá, protože že se nevloupáváte do systému, kam byste přístup neměl mít. Co by se dalo použít, je „překonávání účinné ochrany“ z autorského zákona. (Ostatně si všimněte, že DMCA požadavek vznesli držitelé majetkových práv k obsahu, nikoliv provozovatel služby Youtube.) Problém ale bude dokázat, že se jednalo o ochranu „účinnou“. Navíc čistě právně autorské právo je věc občanskoprávní. Aby se spor přenesl do trestní roviny, musela by škoda překročit 5 000 Kč nebo čin představovat obchodní činnost.

[Bystroushaak]

Co by se dalo použít, je „překonávání účinné ochrany“ z autorského zákona.

Imho jen těžko, protože ten nástroj není jen na youtube, a i kdyby byl, tak na youtube pořád máš mnoho zcela legálních použití (spousta videí je volně šiřitelná a spousta lidí tím stahuje jen svoje díla).

[lol]

spousta lidí tím stahuje jen svoje díla

To nemyslíš vážně, viď?

[Bystroushaak]

Nevím co se mi tu snažíš vecpat, tak to radši napiš rovnou.

[Jendа]

Mně taky přijde divné, že by někdo nahrál svoje video na YT, a pak si ho (po utrpění generation loss) zase stáhl. Jako takový bizarní způsob zálohování?

Jinak i takové použití je proti jejich ToS (pro přístup k službě smíš používat jen oficiální web a klienty). Ale naprosto netuším, jestli u nás je možné takové ustanovení do ToS dát.

[Heron]

Spousta lidí natáčí přímo na YT pomocí třeba mobilu / tabletu.

[:-(]

Spousta lidí natáčí přímo na YT

bez střihu, jistě.

[Bystroushaak]

Mně taky přijde divné, že by někdo nahrál svoje video na YT, a pak si ho (po utrpění generation loss) zase stáhl. Jako takový bizarní způsob zálohování?

Streamování?

A jinak já jsem v minulosti taky nahrál na YT neveřejná videa, která už nikde jinde zálohovaná nemám. Většinou se nejednalo o nic světoborného, použil jsem to tak jak někdo používá třeba pastebin, nebo imgur, prostě k poslání něčeho co jsem zrovna viděl někomu.

[:-(]

A jinak já jsem v minulosti taky nahrál na YT neveřejná videa, která už nikde jinde zálohovaná nemám

Tak to jsi pitotomec.

[:-(]

použil jsem to tak jak někdo používá třeba pastebin, nebo imgur

nejdřív se to musí ale uložit na disk, takže nic přímo nejde.

[Bherzet]

No jo, ale ony ty soubory taky občas něco váží. Už nevím kdo, ale nějaký tytrubkář si tuším stěžoval, že mu smazali video a on už ho nemá zazálohované (chcípl mu disk nebo tak něco).

Stahování vlastního obsahu asi určitě nebude nejběžnější způsob použití youtube-dl, nicméně může se to stát. Ostatně: i YouTube je forma zálohy.

[V.]

Co to, tohle jsem už někdy zažil, že byl připuštěn i neoriginální klient do sítě ... u icq? Precedens?

[petr_p]

ten nástroj není jen na youtube

Primární určení nástroje je relevantní pro dodavatele obcházecího nástroje. Ale jestli ti jde o tohle, tak stačí útočit na konkrétní plugin (youtube_dl/extractor/youtube.py) místo na celý balík souborů. Jinak hodně štěstí ve vysvětlování primárního určení nástroje, který nese Youtube ve jméně.

Zákon ale zrovna tak zakazuje obcházet bez ohledu na nějaký nástroj. To je pro změnu relevantní pro koncové uživatele.

na youtube pořád máš mnoho zcela legálních použití (spousta videí je volně šiřitelná a spousta lidí tím stahuje jen svoje díla).

To je ovšem pro schopnost obcházet zcela nepodstatné.

[xkucf03]

To je ovšem pro schopnost obcházet zcela nepodstatné.

Pomocí příkazů wget nebo ssh můžeš taky porušovat kdejaký zákon. Je pak zcela nepodstatné, že mají i legitimní a legální využití?

[Heron]

No ono je to ještě zábavnější. youtube-dl sám vlastně nic nestahuje, má na to externí nástroje (co používá default nevím, možná curl přes knihovnu). Používal jsem axel, nověji aria2c. Nástroj youtube-dl pouze dodá seznam URL. A navzdory svému názvu ten program fakt není určen jen pro yt.

Tímto extensivním výkladem bychom museli zakázat polovinu programů v repositáři libovolné distribuce a prakticky bychom tak znemožnili její používání.

[billgates]

Tieto nastroje su este take "jemne", ale co taky metasploit alebo rozne softvery typu SoftICE a pod?

[petr_p]

Jestli nevidíš rozdíl mezi obecným HTTP klientem, kterým si opravdu video z YouTube nestáhneš, protože kolem toho potřebuješ logiku se znalostí vnitřností služby YouTube, a nástrojem specializovaným na stahovaní obsahu z YouTube, který právě tu logiku obsahuje, tak ti není pomoci.

[petr_p]

Problém ale bude dokázat, že se jednalo o ochranu „účinnou“.

Teď koukám, že v autorském zákoně, se objevila definice „účinné ochrany“. Je to jakýkoliv mechanismus, který je určen k omezování práv, jestliže [jím] autor může kontrolovat užití díla.

Takže problém se rozpadá na dvě podmínky: Musí tu být určený mechanismus a autor jej může řídit. Kupodivu mechanismus tu je: Youtube nastavuje atribut controlslist elementu video na hodnotu nodownload. Například Firefox to respektuje a odstraní možnost uložit video z kontextové nabídky. Samozřejmě toto pouze vypovídá o přítomnosti ochrany ve webovém přehrávači, který se konstruuje z javascriptového kódu Youtube. Jestli tento „nodownload“ příznak je uveden i v primárních datech, z kterých čerpá youtube-dl, netuším. Druhý problém, jestli autor má možnost hodnotu toho atributu řídit, zodpovědět neumím, protože neznám rozhraní Youtube pro autory.

[petr_p]

Například Firefox to respektuje a odstraní možnost uložit video z kontextové nabídky.

Firefox to nerespektuje. Z YouTube ukládat neumí, protože video je „uloženo“ v URI typu blob.

[Ocelový Myš]

Když už se to tu tak hezky rozjelo, také se zeptám: co hackování herní konzole? Nemyslím teď pirátění her, ale jailbreak za účelem provozu homebrew aplikací. Tohle by se nedalo postihovat jakožto neoprávněný přístup k počítačovému systému? Podle mně ano, ale nejdem právník. Třeba v Japonsku je co vím tohle explicitně zákonem zakázané (jailbreaking).

[Jendа]

Já si myslím, že neoprávněný přístup k nosiči informací by mohlo být i takové to populární zresetování čipu v náplni do tiskárny po té, co se náplň rozhodla, že jí skončila životnost.

A nebo se dá naopak říct, že vlastníš ten hardware (konzoli, náplň) a do své věci si můžeš oprávněně zapisovat cokoli uznáš za vhodné, že.

[paul2no]

Tohle je zajímavé. Byl snad případ, kdy podle toho paragrafu o neoprávněném přístupu k nosiči informací byl postihován nějaký případ manipulace s tachografem u kamionu, ačkoli tachograf je nedílnou součástí auta a auto vlastní jeho provozovatel.

[Jendа]

WOW

[xkucf03]

Např. platební karta je majetkem banky a ty jsi jen držitel. Nebude to tady podobné?

[Jendа]

V tom .doc píšou že ne, a i podle mě je tachograf tvůj (ale náklaďák neprovozuju).

[plostenka]

Nedalo, protoze v CR muzes stahovat audiovizualni dila bez omezeni. Uz mas predplaceno pri nakupu pametoveho media.

[Jendа]

To, že můžeš stahovat AV díla pro vlastní potřebu, neznamená, že za tímto účelem můžeš například exploitovat bezpečnostní díry na FTP serveru Supraphonu, aby sis ta díla stáhl.

[plostenka]

Jasne, ale ytdl nic nehackuje, jen rika curlu jak stahnout data ktera jsou zverejnena uz *pred* spustenim ytdl.

[Jendа]

To už je pak na bitvu právníků, jestli je rozebírání obfuskovaného javascriptu blíž k „stáhl jsem si to z odkazu“ nebo hackování.

[Jendа]

OTOH pokud si to dumpneš z prohlížeče, tak mi to přijde OK, a když youtube-dl vede ke stejnému výsledku, tak by asi taky mělo být OK.

[666]

Smutne
Navic ja jsem to treba k zadnemu "stahovani" nepouzival. Je to temer jediny zpusob, jak v linuxu vyuzit toho, ze moje grafika umi hw h264.

[Neznalek]

Ještě tu je softwise

![SoftWise.ru[:newmediatech.ru,МедиаТех ООО,Юрий,Сергеевич Соболев] !Софтвайс ООО;Валерий Георгиевич Кузнецов;Санкт-Петербург,RU;+7(921)41-13-301 !p:adsterra.com,tubecorporate.com,adspyglass !partner:itmo.ru(Университета ИТМО),.. !i:zfgloadedpopup,WaynePop3 b:kickass.cd,rarbg.com, !ip4:213.174.153.229,198.134.112.243,172.64.139.23,.. !b:sport-stream.ru,live-stream365.com,sportstreamings.com,watchallsports.live !p:k2s.cc,unblockit.top,unblocksource.com,theporndude.com,mrporngeek.com,seaporn.org,toppornsites.com,naughtyblog.org,porn4k.to,freeomovie.to !fb:porncoven.com,jdforum.net,doolls.org,sexandfetishforum.com !db:filejoker.net,fboom.me !ib:imagevenue.com,imgcloud.pw,pimpandhost.com,imagetot.com !ps:o0-1.com,xstreamcdn.com !tb:anonfiles.com,limetorrents.info !ab:site-rip.org,0xxx.io,0xxx.ws,voyeur-house.to,reallifecam.to,.. !sp:gounlimited.to,openload.com,streamango.com,jetload.net,clicknplay.to,netu.io,mixdrop.co,loadshare.org,gcloud.live,vcdn.io !sb:gomovies.tube,gomovies.digital,vidcloud9.com

[Vantomas]

Projekt se přejmenuje a z příkladů použití vyhodí odkazy na ty videoklipy, které tam měli doposud.

[Michal Kubeček]

Jen pro pořádek: ty tři "příklady", které se RIAA snaží prezentovat jako příklady použití ("podívejte, takhle se to používá") jsou ve skutečnosti testcases pro selftest a jsou schované ve zdrojácích, takže drtivá většina uživatelů youtube-dl je nikdy neviděla a neuvidí.

[karel]

Na stránce youtube-dl.org je nejaký podivný pohyb.
Pro jistotu jsem udělal její mirror

[Peter Golis]

Hmmm, github. Majetok firmy MS sa v poslednej dobe stáva nástrojom hackerov, ako píšu v MSNBC. V Televíznej spoločnosti ktorú spoluvlastní firma MS.

Som zvedaví, či si platiaci užívatelia Githubu konečne začnú uvedomovať pridanú hodnotu majiteľa ktorému zverili výsledky svojej práce.

[Fluttershy, yay!]

V Televíznej spoločnosti [MSNBC] ktorú spoluvlastní firma MS.

Už dávno ne.

Co se týče toho tweetu od Rachel „Russia, Russia, Russia“ Maddow, ten neexistuje – resp. jde o fabrikát z /pol/.

Milé děti, nešiřte fake news… neboli lži.

[Peter Golis]

Prečo si kaziť vtip, že? Keď človek nič iného voči hentým zemepánom nezmôže, teda okrem exilu ktorý je v čase globálnej pandémie trochu riskantný.

[Fluttershy, yay!]

Proč lžeš?

[Peter Golis]

Ja neklamem. Uvidíš či aj v tomto prípade zvíťazí právo, alebo peniaze.

[FBI]

Přesne takhle se to má dělat. Nech si piráti nemyslí že můžou všechno.

[эфэсбэшник]

+1

[JanM_262]

-2 U vás je pirát každý kdo stahuje? Protože já vidím jako piráta až toho kdo obsah šíří na pirátských serverech a za to Youtube-DL nemůže. To že je Youtube-DL zneužitelný i pro šíření je věc druhá, stejně jako je nůž zneužitelný pro vraždění. Stahuju z youtube ve velkém a to především z důvodu offline přehrávání nebo jako zálohu pokud by se video z youtube ztratilo, což česká legislativa povoluje. Stejně tak nahrávám ze satelitní TV pomocí dekoderu který z nahrávky z kodovaného kanálu dokáže odstranit DRM a je mi jedno že se to vysílateli nelíbí (používám legální oficiální kartu). Nebo už jsme to dopracovali tak daleko že jsou obchodní podmínky jedné firmy nadřazené platné legislativě? Kromě toho že nerozumím tomu proč se RIAA zabývá stahováním a šířením nečeho co je legálně na youtube dostupné zadarmo. Dávalo by to smysl u placených služeb, ale i tam by měli poskytovatelé řešit až samotné šíření, nikoliv stahování. Před 15 lety všichni odmítali chráněné CD/DVD a jak se podobné ochrany dostanou na internet tak je to v pořádku? Mnozí tyto ochrany tak nějak tupě přijali ale já jsem za tu dobu názor nezměnil

[petr_p]

Změnila se legislativa. Před 15 lety bylo (tady) legální DRM obejít. Dnes tomu tak není. Samozřejmě s ní můžete nesouhlasit, ale to je asi tak všechno, co s tím můžete udělat.

[JanM_262]

Jak se změnila? § 30 o volném užití který povoluje stáhnout všechno je tam stále https://www.zakonyprolidi.cz/cs/2000-121

[petr_p]

Přibyl odstavec 6.

[BLB]

https://www.zakonyprolidi.cz/cs/2000-121

Brát zákon z pochybného webu může jen debil.

[FBI]

A ochrana duševného vlastnictví vám nic neříká? Máte povolení od autorů stahovat jejich videa?

[plostenka]

V CR je zakonne pravo stahovat jakakoli videa, mame predplaceno vypalnym z nakupu pametovych medii.

[petr_p]

Lež. Vaše teze neplatní například na videa nezveřejněná (dle některých výkladů na území státu) nebo na videa opatřená DRM.

[JanM_262]

Nejsem právník, ale z toho zákona lze vyvodit tohle: 1. odkaz (§ 29 odst. 2) se týká toho zda je dílo zveřejněné, to Youtube splňuje, protože je to dostupné zadarmo všem. Omezení by nastalo pokud by bylo sledování podmíněno nějakým předplatným (Netflix, HBO Go). Ovšem nevím zda se to týká i tzv. přenosových kanálů, tedy přenosů mezi přenosovým vozem a budovou vysílatele. Světe div se, přestože se ve vysílacích právech točí velké peníze, jejich zabezpečení je celkem mizerné a tyto bývají zdrojovým signálem pro nelegální streamy sportovních přenosů.

2. odkaz se týká výpalného z prázdných médií (§ 25) a postihů pro výrobce přehrávačů (§ 43 a § 44), především pro Android boxy s Fully loaded KODI a jeho nelegálními doplňky. Nevím ale jestli se to týká i televizních rekordérů. Taky tam je že tyto vyjímky z obou odkazů omezují právo na volné užití díla (§ 30 odst. 6).

Možná jste slyšel o operačním systému Enigma2 a značce DreamBox (dnes je více takových značek). Můžu potvrdit že zejména u satelitní TV se dají v obchodech bez problému sehnat STB které automaticky odstraňují z přijímaného signálu ochranu DRM a nahráváním vznikne soubor .TS bez jakékoliv ochrany, který lze přehrát na čemkoliv, překonvertovat do MKV nebo jiného formátu a samozřejmě dále sdílet na ulozto a jiných. Toto je i v továrním firmware, zapnuté defaultně, nejde to většinou vypnout a mnoho lidí o tom ani neví. Nevím jak se k takové funkci staví zákon, ale je pro domácí použití tolerovaná a postihuje se až samotné sdílení souborů na uložto, tedy postup přesně podle podmínek volného užití. Stejně tak dokáže takový přijímač jednoduše "vyrobit" IPTV stream (zvládne to průměrný uživatel na pár kliknutí myší), zde se opět trestá až jeho sdílení na internet. Na to se používá ochrana karty pomocí modulu do PCMCIA sběrnice, která umožní takto nahrávat nebo vysílat současně pouze jeden kanál, což vyloučí možnost zneužití boxu pro nelegální IPTV. Toto mají dnes téměř všichni operátoři (poslední kdo přestal nabízet kartu která funguje v běžné UNI čtečce bez limitu byl freeSAT) a přijde mi že toto je z mého pohledu přijatelná úroveň ochrany která vyřadí pirátské vysílatele, ale normální uživatel nic nepocítí. Některým operátorům ale toto nestačí a požadují pro příjem pouze schválený certifikovaný hardware. Nejmenovaný operátor se mi na pobočce vysmál že je to přesně z důvodů které jsem uvedl nahoře. To zda má vysílatel patřičnou vysílací licenci pro ČR (což taky neplatí vždy) by vyšlo na jiné vlákno, protože mnozí jsou mimo dosah RRTV a jako "přeshraniční přesah" vysílají tady na základě práv platných v jiných zemích Evropy, přestože má někdo jiný exkluzivitu pro ČR.

Ale zpátky k internetovému přenosu, už chápu proč poskytovatelé obsahu tolik tlačí distribuci přes internet. Je to totiž jediná technologie kde můžou plně vymáhat práva související s DRM a kontrolovat úplně všechno, tedy i další fenomén moderní doby a to geoblokace. Jestli má být internet jednou jediným distribučním kanálem pro multimédia a bude to za těchto podmínek, tak potěš Pán Bůh. (nejsem věřící).

[BLB]

Nejsem právník

Ovšem že ne, jsi jen hloupí ale když budeš chtít stále to můžeš více či méně vylepšit, naděje ještě žije

[Fluttershy, yay!]

Duševní vlastnictví je jako panenské početí. Ještě ho nikdo nikdy neviděl, ale jako heslo ve svatých válkách to postačuje.

[billgates]

Nieco ako spolocenska zmluva alebo verejny zaujem.

[xkucf03]

Je zajímavé, jak Piráti víceméně už upustili od svého původního pirátského programu a snahy reformovat autorské právo. Asi tuší, že by jim rapidně klesla podpora, protože mezi jejich voliči jsou buď přímo autoři/umělci nebo lidi, kteří mají v těchto kruzích kamarády a příbuzné – a pro ně je nepředstavitelné, že by měli přijít o ochranu danou autorským právem a honoráře. A umělci/autoři, kteří si dokáží představit fungovat jinak, tak ti už vydávají svoje díla pod Creative Commons nebo dělají třeba svobodný software, v čemž jim autorské právo jako takové nijak nebrání.

[Fluttershy, yay!]

V současné sněmovně neprošly ani pozměňováky ke sněmovnímu tisku 175 (Novela z. - autorský zákon - EU).

[JanM_262]

Nějak jsem si nevšiml že by se kontroverzní článek 13 projevil. Zákon platí ale jinak se nic nezměnilo

[Dr P]

#155

Takhle to ale nepůjde.

[xkucf03]

Tady nejde o aktuální složení poslanecké sněmovny, ale o celkovou náladu ve společnosti a o voličskou základnu. Na ty ostatní poslance se můžeš sice vymlouvat, ale je to celkem irelevantní.

Kdybyste cílili na nějaké libertariány a anarchokapitalisty, tak u nich byste se možná s pochopením pro váš původní pirátský program v oblasti autorského práva setkali. Ale když cílíte na marxistické nebo obecně levicové voliče (možná s nějakým malým přesahem ke středovým voličům), tak tam je ten váš původní program na obtíž. Jak jsem ti psal výše, tito lidé mají buď přátele v uměleckých kruzích (nebo umělci přímo jsou) a¹ budou s nimi sociálně cítit – budou se tě zákonitě ptát, co ten umělec bude jíst a z čeho má žít, když omezíš nebo dokonce zrušíš autorské právo. Budou ti říkat, že už takhle na tom umělci nejsou moc dobře, natož aby se to ještě zhoršilo. Anarchokapitalista by řekl, že ho to nezajímá, a ať si ten autor třeba chcípne hlady nebo jde dělat jinou práci, je to jeho problém, ne můj, takže ten by ti nepříjemné otázky o autorském právu, na které nedokážeš odpovědět, nekladl (ale zase by měl problém s jinými částmi tvého programu). To ale není typický volič Pirátské strany. Příznivcům původního programu se tedy nějak bokem vymluvíte, že za to můžou ti oškliví poslanci z jiných stran, že se to nepovedlo, a současné voliče těmito tématy raději nebudete dráždit, abyste je neodradili. Pokud by k nějaké „reformě“ autorského práva přeci jen došlo, tak by to bylo v režii těch vašich většinových marxistů, kteří budou „sociálně cítit“ s autory. A jak to asi může dopadnout? Asi byste zrušili nějaké ty poplatky, umožnili byste užívání autorských děl v rozporu s licencí/vůlí autora (de facto znárodnění), tím byste asi oslovili nějaké mladé dredaté voliče, ale na druhé straně by autorům pak vyplácel podporu přímo stát, aby bylo dosaženo „sociální spravedlnosti“. Všechno by to tedy zaplatil daňový poplatník a ve výsledku by to bylo méně svobodné, než současný stav, protože dneska můžu alespoň nemít televizi/rádio a neplatit za ně poplatky (kdežto daně platit musím).

_{[1] ve smyslu „a zároveň“ – což je důležité, protože rozhodně ne každý umělec je levičák}

[Fluttershy, yay!]

Co ty víš o voličské základně Pirátů? Četl jsi ty příslušné analýzy? V médiích se říká, že volič Pirátů je potomek voličů ODS. To má z hlediska „společenských nálad“ jeden zajímavý aspekt: volič(ka) Pirátů vyrůstal(a) na upirátěných hrách/filmech/hudbě a i u těch liberálních rodičů, kteří třeba mají plná ústa toho, jak se má za všechno platit, najdeme knihovničku kopírovaných cédéček/kazet. Jenže ona to není celá realita: další voliči jsou na sídlišti, na dědině,… Piráty dneska volí normální pracující třída. To za prvé.

Za druhé, umělci – aspoň před pandemií – měli také vernisáže, happeningy a kdesi cosi. Ty mají s kopírovacím monopolem jaký souvis? (Ano, mají, leč opět jde např. o vztah s institucemi; ostatně RIAA z OP je organizace vydavatelů – marxista rozumí, že jde opět o kapitalisty, kteří kradou plody práce umělců samotných.)

Konečně, nejde zdaleka jen o provařené torrenty. Nemohu nevzpomenout např. demonstrace proti ACTA, tedy příkladu mechanismu globální hegemonie euroatlantického kapitálu, přičemž se dotýká celé škály témat včetně např. dostupnosti generických léčiv, a tedy elementární humanitární problematiky zvláště v rozvojových zemích.

[xkucf03]

V médiích se říká, že volič Pirátů je potomek voličů ODS. To má z hlediska „společenských nálad“ jeden zajímavý aspekt: volič(ka) Pirátů vyrůstal(a) na upirátěných hrách/filmech/hudbě

Já tu dobu pamatuji a tehdy nelegálně kopírovali všichni – bez ohledu na společenské postavení nebo politické preference. Nemá to nic společného s těmi lidmi, taková tehdy byla doba.

a i u těch liberálních rodičů, kteří třeba mají plná ústa toho, jak se má za všechno platit, najdeme knihovničku kopírovaných cédéček/kazet

Spousta lidí se dnes kloní k výkladu, že „mají předplaceno“ a sem tam si něco ukrást je tedy v pořádku, nebo je to takový malý hřích, ze kterého se zase jindy vykoupí tím, že půjdou na koncert, zaplatí za cédéčko, tričko atd. Ale to neznamená, že by chtěli umělce odříznout od jejich příjmů a honorářů a zničit ten současný systém. Ten totiž většině lidí tak nějak vyhovuje (byť na něj občas nadávají).

[Fluttershy, yay!]

Pomohlo by občas vykouknout mimo svou sociální bublinu, potažmo nahlédnout do četných mj. sociologických průzkumů.

[BLB]

Co píše je čistá pravda, naopak to co píšeš ty je takový balast, dojmů? nevím ale je to o ničem.

[kralyk z abclinuxu]

tak by to bylo v režii těch vašich většinových marxistů (...) Asi byste zrušili nějaké ty poplatky, umožnili byste užívání autorských děl v rozporu s licencí/vůlí autora (de facto znárodnění), tím byste asi oslovili nějaké mladé dredaté voliče, ale na druhé straně by autorům pak vyplácel podporu přímo stát, aby bylo dosaženo „sociální spravedlnosti“

Omg. Že tady tyhle pindy šíří Phantom, na to jsem zvyklej, od tebe bych to až tak nečekal... Asi chyba lávky.

[xkucf03]

A dovedeš si představit jiný výsledek? Na jednu stranu se chceš zalíbit zablešeným dredům a umožnit jim zdarma beztrestně stahovat/sdílet – a na druhé straně tu máš soudruhy a soudružky ohánějící se „solidaritou“ s umělci.

Pokud řekneš, že lidi můžou chodit na koncerty, vernisáže, dobrovolně přispívat autorům, tak že je to uživí, a ti můžou publikovat pod svobodnou licencí… tak to můžou už teď – kvůli tomu nemusíš rušit autorské právo (nebo jak soudruzi říkají „kopírovací monopol“).

[JanM_262]

On se z toho ten kopírovací monopol téměř stal. Práva drží velké firmy a ty autora nepodpoříš ani kdybys chtěl. Jako jednotlivci ti to za pár stovek neprodají a velkoobchodní cena v řádu stovek milionů za vysílací práva je dobrá zase jenom pro jinou velkou firmu. Tady nejde o potřebu zablešenců ušetřit pár stokorun, ale o nemožnost se k dílu vůbec dostat bez ohledu na cenu. Je nutné se spoléhat na to že to za velkoobchodní cenu koupí velká firma a ta to zpřístupní obyčejným lidem a ten zase musí skákat podle toho jak vlastník práv píská (časové omezení, geoblokace...) Používám pirátské servery, ale pouze proto že není někdy není jiná možnost.

Nebo máte na mysli hudebníky kde je situace o dost lepší a potřeba pirátství tam téměř vymizela? Já mluvím o filmovém/video průmyslu.

Více v tomhle komentáři https://www.abclinuxu.cz/zpravicky/dmca-pozadavek-na-zastaveni-sireni-zdrojovych-kodu-youtube-dl-na-githubu/diskuse#144

[kralyk z abclinuxu]

Diskutovat stylem "volyč SPD se ve čtvrté cenové baví o Pirátech" můžu maximálně s jedním člověkem, Phantom mi na tohle stačí více než bohatě. Druhého takového opravdu nepotřebuju, takže nezlob se, ale v téhle diskusi pokračovat nebudu.

[JanM_262]

budou se tě zákonitě ptát, co ten umělec bude jíst a z čeho má žít, když omezíš nebo dokonce zrušíš autorské právo

Možná jste myslel spíše hudebníky, ale ve filmovém průmyslu tady zatím nikdo nezmínil ještě jednu důležitou věc a to v některých případech legální distribuce vůbec neexistuje, přestože se jedná o dílo zveřejněné téměř vždy v těchto případech odvysílané v TV vysílání, nikdy nevyšlo na DVD a není v žádné streamovací službě. Na Živě.cz se tomu vysmáli že to není možné a že Netflix má všechno, ale mi se to v poslední době stává u cca 70% obsahu. Netflix, Amazon Prime a HBO Go tedy nepoužívám, protože většinu požadovaného obsahu tam nenajdu. Týká se to především pořadů vytvořených na míru pro konkrétní TV kanál. Hledám především reality show a TV soutěže jako The Voice Kids nebo Star Academy. Jediným zdrojem je poté vlastní nahrávka z TV nebo pirátský server, pokud nepočítáme extrémní případy jako přímá komunikace s vlastníkem práv, kterým bývá většinou společnost BaniJay (dříve Endemol) - tento postup jsem nezkoušel. Toto není o "sociálním cítění" s autory, ale o tom že autoři chtějí potírat pirátské servery, ale nejsou schopni za ně nabídnout legální náhradu. Archivy TV stanic s dostupností na 14 dnů opravdu nelze brát vážně. Tím mi autor říká že o moje peníze nestojí a odkazuje mě na pirátské servery. To co se u hudby povedlo a máme tu Spotify, Apple Music nebo YTM se u videoobsahu stále nedaří a je tu obrovská díra na trhu. Pokud tedy někdo vytvoří streamovací službu která tenhle typ obsahu nabídne za odpovídající cenu, tak jsem ochotný přijmout i to že bude mít DRM ale musela by splnit 2 podmínky:

1. bude mít dostatek obsahu v kategorii realityshow/TV soutěží

2. bude to dostupné bez časového omezení

Takovou by teoreticky mohl spustit zmíněný BaniJay/Endemol, který má práva snad na všechno. Mají přes 80 000 hodin obsahu snad ve všech světových jazycích, ke kterému se ale nikdo nedostane

[Heron]

Tak tohle je klenot

Koukám, že sis našel další terč k hatování a ještě do toho umě zavlečeš všechno statní.

Jinak myslím, že máš základní chybu v úvaze a to tu, že vůbec nezmiňuješ takzvané ochranné svazy a nahrávací / distribuční firmy. Nikdo nechce poškozovat umělce, jak tady fabuluješ, cílem je zrušit ty překupníky uprostřed a spojit umělce rovnou se zákazníky / fanoušky.

V digitální době no problémo, ty prostředníci vůbec nejsou potřeba. A ti jen kopou kolem sebe, někdy víc (třeba teď), někdy méně.

[JanM_262]

Pokud autor zpřístupnil video na Youtube, už by neměl kecat do toho kdy a na čem ho budu sledovat.

[knownoter]

Tady anonym poslal filtry pro youtube, tak jim to vrať

https://pastebin.com/V4KhnDWc

[Gréta]

to vodnich nebylo ani hezký ani chytrý protože lidi co youtube-dl používaj si ho seženou vodjinud a vobyčejný lidi stejně používaj různý takový ty webový aplikace na stahování z yt :O :O :D :D ;D ;D

to zas někdo někde žvanil a lidi coby jako vživotě vo nějakej takovej nástroj nezavadili se uplně zděsili když zistili žeje něco takovýho technicky možný :D ;D

[Bherzet]

Pomocí programů SimpleScreenRecorder a dalších obdobných je také možné obcházet technologická omezení a pořizovat neautorizované kopie autorských děl. Měli bychom o tom RIAA vyrozumět: lepší příležitost, jak zařídit migraci projektů do temných zákoutí Internetu zcela mimo dosah US/EU zmrdů, se nemusí dlouho opakovat.

[Bherzet]

Greetings, bitches,

Dear Sir or Madam,

it has come to my attention that software products such as SimpleScreenRecorder, Kazam, OBS Studio, recordMyDesktop, VokoscreenNG, ScreenStudio, Green Recorder, Peek, Gifine and many others allow users to (i) circumvent the technological protection measures used by authorized streaming services such as YouTube, and (ii) reproduce and distribute music videos and sound recordings owned by your member companies without authorization for such use.

Please do take them down.

With sincere wishes of slow painful death,

FUCK YOU.

Kind regards,

John Smith

[kralyk z abclinuxu]

neautorizované kopie autorských děl

Mimochodem, jak se liší autorské dělo od běžného děla?

[Bherzet]

Autoři často vedou bohémský život, který jim plebs při čtení bulvárních plátků závidí. A tak se je občas pokusí napodobit: nezlijou se jako dělo, jak obyčejně činí v pátek po setmění, ale zkusí si mimo tuto obvyklou dobu, drahými víny a v pěknějších oblečcích než snad obvykle nosí, osvojit dělo autorské. Typicky se tak děje ku příležitostem svateb či jiných, z jejich pohledu významných, společenských událostí. Z pohledu majitelů práv – narozdíl od plebsu, který žádná práva nemá – se však jedná o neautorizovanou kopii autorského děla. Proto proti tomu mocipáni z Evropské upije a Spokojených slastistátů alkoholických tak tuze brojí.

[JanM_262]

Jenže vytvořit kopii pomocí těchto programů už není zase tak jednoduché. Kromě toho že třeba VOD služba myCANAL už dokáže vyřadit i tyto. Pak je tu další level. Grabovací karta

[abdul hassan huseiny]

Komentar #100

[JanM_262]

Jak toto ovlivní snapy v linuxových distribucích?

[petr_p]

Nijak. Vlastníci majetkových práv budou muset podat stejnou žádost každé distribuci zvlášť (pokud má registrovaného DMCA agenta), nebo prokázat u soudu protizákonnost onoho programu a pak se soudit o zákaz šíření (a náhradu škody, o kterou jde především) s každou distribucí. Ostatně DMCA není o tom, kdo je nebo není v právu. Je to o tom, že za 6 dolarů na 3 roky se může distributor vyvinit z plnění náhrady škody.

[xkucf03]

Jak se spočítá náhrada škody, když jsi jen jeden z mnoha distributorů a nebýt tebe, tak si lidi stáhnout daný software odjinud, klidně třeba přes Tor nebo I2P?

[odpadlik]

Já úplně nejvíc žeru jak se tady neustále šermuje s tím, že youtube-dl je nástroj ke stahování, ale není tomu tak. Nejen k tomu. Youtube-dl je už docela dlouhou dobu integrován do mpv, kde slouží právě jako přežvýkátor služby do streamovatelné URL s tím že samotný proud není stahován nýbrž kešován a zobrazen úplně stejně jako při legitimní sledování. Akorát bez tuny otravných reklam, dotazů, s podporou HW akcelerace. Když bych měl vše co mi youtube-dl přežvýkal stahovat, v podstatě už na to ani nemám místo na disku. V poslední době jsem si velice oblíbil na sledování některých pořadů TV Nova poté co mi odstřihli DVB-T a stal se z toho prakticky jediný způsob jak se k jejich obsahu dostat (jejich stránky navštěvovat odmítám, DVB-T2 televize bude v budoucnu).

[Martin Tůma]

Mě by hlavně zajímalo, jestli už někdo z Microsoftu vyrazil na Špicberky stříhat celofany, když jsou tak proaktivní a v rozporu s jejich vlastníma pravidlama odstranili i forky, který v tý DMCA notice vůbec nejsou...

[commit se zdroji ne nyni rovnou v dmca repu]

Tedy to je: https://github.com/github/dmca/tree/416da574ec0df3388f652e44f7fe71b1e3a4701f

[kralyk z abclinuxu]

Hezké, mohli by na tom založit workflow vývoje.

Chce přispět kódem? Pošlete pls DMCA takedown notice...