Apple představil nový MacBook Pro s čipy M4, M4 Pro a M4 Max.
Na GOG.com běží Halloween Sale 2024. Při té příležitosti lze získat zdarma počítačovou hru Return of the Phantom.
Společnost OpenAI spustila internetový vyhledávač ChatGPT search.
Konference OpenAlt 2024 proběhne již tento víkend 2. a 3. listopadu v prostorách FIT VUT v Brně. Začíná ale už v pátek na warm-up party ve Studentském klubu u Kachničky v 17:00. Pokud jste ještě areál FITu nenavštívili, k dispozici jsou pokyny k orientaci. Na programu je 54 přednášek a workshopů. Témata jsou od silně technických témat jako je třeba GCC nebo PostgreSQL po méně technické témata jako eGovernment, nebo třeba detailní analýzu … více »
Byla vydána nová verze 6.9 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 14.0.1. Tor client na verzi 0.4.8.13. Thunderbird na verzi 115.16.0.
Vývojáři free a open source synchronizačního nástroje (a p2p náhrady Dropboxu) Syncthing oznámili, že z důvodu odporu ze strany Google Play ukončují podporu OS Android. Bohužel v rámci toho zmizí i vydání Syncthing na F-Droid, který má slabší uživatelskou základnu. Syncthing je na Androidu implementován formou wrapper aplikace, která spustí Syncthing démon, vyžádá potřebná oprávnění a zpřístupní webové rozhraní démona. Ve srovnání se
… více »V červnu 2022 bylo oznámeno, že z K-9 Mailu se stane Thunderbird pro Android. Trvalo to poněkud déle, než vývojáři předpokládali, ale včera byl první stabilní Thunderbird pro Android 8.0 vydán.
Projekt microDMG Racer na Kickstarteru nevyšel, tak se autor rozhodl uvolnit na ESP32 postavené autíčko i ovladač jako open source.
Byl vydán TrueNAS SCALE 24.10 „Electric Eel“. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Byla vydána nová verze 24.10.29 svobodného multiplatformního video editoru Shotcut (Wikipedie) postaveného nad multimediálním frameworkem MLT. Nově s podporou AI (whisper.cpp) pro generování titulků. Nejnovější Shotcut je již vedle zdrojových kódů k dispozici také ve formátech AppImage, Flatpak a Snap.
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.
Tiskni Sdílej:
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ářů.
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ě.
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.
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 ...
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é pornografie1 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é
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.
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).
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:
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.
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é.
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.
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.
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.
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.
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...
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.
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.
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í).
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ářeGit 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ů.
/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.
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 GithubuGitu 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ů.
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…
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.
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 identit1 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
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á.
Původně tu Bherzet zmiňoval jak zabránit přepisování historie komentářů v těch metadatechNe, 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ý.
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?
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.
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
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 nothingExcept for the whole world of opensource. To o čem tam mluví oni jsou finanční blockchainy.
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čí:
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…
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.
Blockchain, the amazing solution for almost nothingExcept 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é.
na toho kdo dělá pull request.Přijímá. Ale jinak souhlasím, Git je/používá blockchain.
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?
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.
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.
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.
{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.
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:
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.
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...
Ř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.
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…
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).
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 brancheAha, 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.
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í.
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.
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.
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ányV 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 ...
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ů
Btw dívám se, že Joey taky udržuje seznam distribuovaných bug trackerůTo je velice zajímavý seznam. Díky.
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í.
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ší).
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.
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 softwareTo 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).
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.
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...
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.
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č
Tady se bavíme o období několik let zpětAha, 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.
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 .
* 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.
$ 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
$ 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í.
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.
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)
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...
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).
spousta lidí tím stahuje jen svoje dílaTo nemyslíš vážně, viď?
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ámTak to jsi pitotomec.
použil jsem to tak jak někdo používá třeba pastebin, nebo imgurnejdřív se to musí ale uložit na disk, takže nic přímo nejde.
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é.
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í?
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í.
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.
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.
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.
Např. platební karta je majetkem banky a ty jsi jen držitel. Nebude to tady podobné?
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
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.
https://www.zakonyprolidi.cz/cs/2000-121Brát zákon z pochybného webu může jen debil.
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í.
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) a1 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
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í).
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.
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“).
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
neautorizované kopie autorských dělMimochodem, jak se liší autorské dělo od běžného děla?
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?
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...