Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?
K tomu slouží git stash
– je to něco jako kdyby sis udělal git diff
výsledek pojmenoval a někam uložil pro budoucí použití a změny v pracovním adresáři zahodil. Udělat klasický git commit
(--amend
), je taky cesta, ale tam hrozí, že člověk na rozdělanou práci zapomene a omylem udělá git push
.
Popis může být i víceřádkový. Součástí řetězce v souboru .git/config pak bude i sekvence pro zalomení řádku.
Ty popisy jsou ale jen lokální, ostatní je nevidí, ne? Při týmové práci bych spíš větev pojmenoval podle čísla úkolu ze systému na správu chyb/požadavků (Bugzilla atd.) a podrobný popis měl tam.
Ty popisy jsou ale jen lokální, ostatní je nevidí, ne?Ano. Ale to je přesně to, co jsem od toho očekával. Ty popisy jsou určeny především pro mne, abych si po čase snáz vzpoměl proč jsem onu branch buď já, nebo autor aplikace vlastně založil. Někdy samozřejmě stačí pouhé pojmenování větve, ale v některých případech ne. Navíc nemám ambice, ani čas na to, abych participoval na vývoji kdejaké aplikace. Pokud potřebuji vyřešit nějaký problém, založím si branch, pro sebe problém vyřeším a pokud to má valný smysl i pro někoho jiného, pošlu autorovi patch a nechám zcela na jeho libovůli jak s ním naloží.
Jenže jak stáhnout aktuální změny v hlavní vývojové větvi, když se na ni bez uložených změn nemohu přepnout?
git fetch
stáhne změny z remote, aniž by cokoliv měnil v lokálním repu.
BTW: jak řešíte situaci, kdy si chcete zazálohovat vzdálený git? A tím myslím kompletně – všechny větve.
--mirror Set up a mirror of the source repository. This implies --bare. Compared to --bare, --mirror not only maps local branches of the source to local branches of the target, it maps all refs (including remote-tracking branches, notes etc.) and sets up a refspec configuration such that all these refs are overwritten by a git remote update in the target repository.
A následný pull
/fetch
přes všechny větve?
Stačí fetch, pull je jen zkratka pro fetch + merge a ten merge už můžete udělat lokálně. Takhle to třeba řeším na notebooku, kde je dobré mít fetchnutý co nejvíc akutální stav, ale není nutné mít aktuální i lokální tracking branche, protože to už můžu v případě potřeby udělat i offline. Takže když jsem online, pustím něco jako
for d in ~/work/git/*; do git -C "$d" fetch --all; done
a update lokálních větví nechám až na moment, kdy je opravdu chci použít.
Mně právě někdy přišlo, že git nepostahuje všechno, ani když dám fetch --all
. Ale teď jsem to zkoušel a vypadá to OK.
[remote "upstream"] url = $REPO fetch = +refs/heads/*:refs/remotes/upstream/*Takhle jsou automaticky napr. z githubu stahovat i pull requesty do prislusne vetve
[remote "upstream"] url = $REPO fetch = +refs/heads/*:refs/remotes/upstream/* fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*
GitHub je proprietární služba. Když už tak něco jako GitLab, Kallithea atd. A nebo pak třeba Fossil, což je verzovací systém, který má vestavěnou wiki i správu chyb/požadavků.
GitHub je proprietární služba.To je sice pravda, ale na GitHubu ani tak nejde o tu službu, jako spíš o tu komunitu a viditelnost. Pro vlastní účely si člověk určitě může nahodit GitLab nebo cokoli jinýho, ale imho veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu. Může se nám to nelíbit, ale je to tak ...
Aby moje předchozí tvrzení neznělo tak radikálně: zrovna u distribuovaných verzovacích systémů není proprietární služba resp. hosting až taková tragédie, protože úložiště se dá kdykoli naklonovat, vystavit jinde a uživatelé si jen změní URL. Taky nehrozí ztráta dat, protože autoři mají všechno i u sebe. A integritu lze zajistit elektronickým podpisem jednotlivých verzí.
Nicméně i přesto mi to trochu vadí a považuji to za problém (i když jsou mnohem horší věci). Např. jde o to, že s GitHubem musíš uzavřít smlouvu, vzdát se různých práv a k jiným věcem se zase zavázat. Prostě typické právnické sračky jako u jiného proprietárního softwaru. Taky to běží v USA a podléhá jejich právu (patenty, jejich výklad copyrightu…).
veřejný foss projekt potřebuje dnes alespoň mirror na GitHubu
A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní… A zrovna u distribuovaného verzovacího systému je to vážně hloupé a zbytečné – jeho zásadní vlastností je právě ta distribuovanost/decentralizace. A nutnost mít účet u jednoho konkrétního poskytovatele gitového hostingu jde přímo proti této myšlence.
Mělo by být jedno, kde je ten repozitář uložený – technologie to podporuje. A pokud jsou potřeba nějaké dodatečné funkce (úkoly, pull requesty, wiki, statistiky atd.), měl by je pokrývat svobodný software – ne proprietární služba.
s GitHubem musíš uzavřít smlouvu
Jde to řešit tak, že si vytvoříš falešnou identitu, nějakého svého virtuálního kolegu, který s GitHubem tu smlouvu uzavře, a bude dělat pravidelně git push
a git pull
a synchronizovat tak úložiště. Primární ale musí být u tebe a vždy musíš být připraven na to, že hosting na GitHubu může kdykoli skončit. Ten kolega bude ve skutečnosti robot a to, že uzavřeli smlouvu s robotem je jejich problém nikoli tvůj.
Na tyhle proprietární služby bych se nespoléhal, je to stejný případ jako třeba YouTube nebo Facebook – jsou lidé, kteří si tam vybudovali síť přátel/kontaktů a pak o ni jednoho dne přišli, protože se provozovateli nelíbil nějaký jejich obsah nebo se třeba jen nějaký jejich pracovník spletl. Komunikace s takovou korporací a snaha o nápravu je jen ztráta času. Viděl jsem např. lidi doporučující si budovat i paralelní síť přátel na VK.com. Ale to je trochu z bláta do louže (záleží taky na politických postojích a možných konfliktech zájmů).
Tak jako tak si člověk musí udržovat záložní komunikační kanál pro případ problémů. Jenže když už člověk tu záložní infrastrukturu má, tak proč ji nepoužít rovnou jako primární místo té proprietární služby? Kvůli šířce pásma a lepšímu pingu do různých částí světa? Kolik dat vlastně potřebujete hostovat a jakou latenci vyžadujete, aby tento argument byl vůbec relevantní?
A to je právě špatně. Je to trochu taková davová psychóza, připomíná mi to časy ICQ… Jsi tam, protože tam jsou všichni a oni tam jsou, protože tam jsi ty a ostatní…Ano, tak to funguje. Viz network effect / bandwagon effect. Přijde mi, že diskuse, jestli to je nebo není špatně je tak trochu bezpředmětná. Já taky mam samozřejmě radší svobodné služby oproti proprietárním. Terms & conditions, NDA a podobně se mi taky nelíbí. Na úrovni teorie souhlasim s těmi ideály o svobodných decentralizovaných slulžbách, nicméně reálně to jde celé do kopru ve chvíli, když si spočteš, že pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešení. (Inb4 elitistické racionalizace á la "Uživatel, který nechce reportovat do našeho systému nám nestojí za to a stejně nejspíš píše blbý bugerporty.") Časy ICQ ti to přípomíná správně, ty časy se nijak nezměnily. ICQ nebylo nahrazeno Jabberem, nýbrž Facebookem. A jestli něco nahradí Facebook, nejspíš to zase bude nějaká proprietární centralizovaná služba spíš než nějaká Diaspora nebo podobné softwary, které jsou sice docela hezké, ale bohužel šanci na reálné využití mají mizivou (a to i přesto, že existují lokální extrémy). Nejsem nijak proti svobodným alternativám populárních služeb, občas je zkoušim, ale v jejich úspěch moc nevěřim. Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...
Spíš si myslim, že to časem dospěje k tomu, že přibudou "socialistické" zákony na regulaci digitální infrastruktury, včetně všelijakých služeb (podobně jako "socialistické" zákony, které regulující volnný trh), ale myslim si, že bude ještě nějakou chvíli trvat, než k tomu společnost dospěje...
Zrovna vedle na Rootu: Londýnský starosta na SXSW 2018: technologické firmy nejsou nad zákonem:
Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách. … Pokud sítě jako Facebook, Twitter či YouTube a další nevezmou existující problémy vážně, může je potkat regulace ze strany vlád. V tomto kontextu připomněl nedávné úpravy zákonů v Německu, které umožňují pokutovat provozovatele sítí až 50 milióny eur, pokud neodstraní hanlivý příspěvek do 24 hodin. Khan by nerad viděl, aby to (regulace) zašlo tak daleko, neb tyto formy regulace nejsou v souladu se svobodou projevu.
Decentralizovaná sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet… Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.
Nebo: Vlády přesměrovávají uživatele na software doplněný o malware:
Avast, CCleaner, VLC, Opera, 7-Zip a další populární aplikace. Pokud se je pokusíte stáhnout v Turecku, dostanete k nim zvláštní dárek – malware. … Turecko se svým poskytovatelem Türk Telekom však není jedinou zemí, kde byla tato praktika objevena. Stejné zařízení pro zkoumání provozu bylo objeveno také v Egyptě u společnosti Telekom Egypt.
Německo, Turecko, Británie, Egypt a další země… tyhle nezdravé myšlenky popírající svobodu se šíří všude možně, takže si nemyslím, že jde o nějakou přehnanou paranoiu.
Decentralizované sítě jsou prostě nutnost, jinak nám zase stát bude nařizovat, co smíme říkat, co si smíme myslet…V čem je výhoda sítě, která je decentralizovaná, liberální a necenzurovaná, ale na které nikdo není? Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí? Čimž určitě nechci schvalovat cenzuru sociálních sítí ze strany státu, jenom mi není jasný, v čem je praktická hodnota toho tvého tvrzení. IMHO pravděpodobně má mnohem větší šanci na úspěch snaha o nastavení smysluplnějších pravidel pro Facebook než snaha o protlačení Diaspory apod. *) Tímto se omlouvám davkolovi, který byl tuším můj jediný kontakt na Diaspoře, když jsem ji zkoušel používat.
Nebo: Vlády přesměrovávají uživatele na software doplněný o malwareV čem je pointa? Repozitář mého distra je v zásadě centralizovaný, stejně jako repozitáře ostatních dister. Ten odkaz je prostě akorát o tom, že Turecko není právní stát a stojí to tam za *****.
Je to sice totálně cynické, ale i cenzurovaný Facebooku má stále větší užitnou hodnotu než třeba ta Diaspora, protože tam prostě nikdo není*. Je sice hrozně hezké, že si tam můžu napsat co chci, ale k čemu mi to je, když to nikdo neuvidí?
S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli. Publikovat tam nějaký užitečný obsah (tzn. poskytnout provozovateli práva, licenci, svoje data…) dává smysl leda za účelem získání těch příznivců. Takže tyhle sítě jsou dobré leda tak pro různé kremloboty/euroboty/sorošboty/aláhoboty a podobné. A do toho tam pumpují explicitní nebo častěji skrytou/neoznačenou reklamu různé firmy a dotují různé tragédy a klauny, smyslem jejichž existence je získat „popularitu“ a příznivce a pak šířit reklamu pro toho, kdo zrovna platí.
S tím souhlasím – pokud potřebuješ získat davy příznivců nebo rozšířit nějakou informaci průměrnému obyvatelstvu, tak jsou sociální sítě jako Facebook nebo YouTube velice dobrá volba. Tzn. využít je v některých případech dává smysl. Na druhou stranu ale není důvod tyto sítě a obecně tento způsob myšlení podporovat tím, že bys tam publikoval něco užitečného nebo to používal pro normální kontakt se svými přáteli.Ok, kterou sociální síť doporučuješ na kontakt s přáteli?
Pro 1:1 klasicky e-mail a Jabber (pokud možno šifrovat). A pro m:n komunikaci opět klasické blogy, RSS/Atom a servery typu Ábíčko nebo různé komunitní weby.
Webové videokonference fungují pěkně na meet.jit.si. (zatím jsem nezkoumal, jak je to tam s odposlechem, ale neříkal jsem tam nic důvěrného, co bych neříkal na veřejném místě, jako je třeba hospoda nebo tramvajová zastávka)
To záleží, jak definuješ sociální sítě. Ze společenského pohledu jsou to okruhy tvých přátel a známých1. Z pohledu IT je to pak nějaká technologie/platforma, která ti umožňuje s těmito lidmi komunikovat a to buď 1:1 nebo 1:N.
Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).
[1] rodina, sousedi, spolužáci z různých škol, kolegové z různých prací, kamarádi z různých sportů a kroužků, náhodní lidé, které jsi potkal atd.
Proč by tou platformou nemohl být web a e-mail? Webový prohlížeč a e-mailovou schránku mají všichni (minimálně všichni ti, které bys mohl potkat na proprietární sociální síti typu Facebook).Webový prohlížeč mají všichni ale svůj vlastní web nemají a nebudou ho mít. Dále ani web ani e-mail nemají to UI, které by se vyrovnalo té sociální síti. E-mail pokrývá pouze relativně malou podmnožinu té funkcionality.
Kdysi jsem napsal článek o tom, že sociální sítě jsou jen taková lepší RSS čtečka.Třeba Facebook v tomhle režimu používám z relativně malé části. Usecase "RSS čtečka" je vhodná na veřejný obsah. (Navíc popravdě RSS čtečky mi nikdy k srdci moc nepřirostly a jsou orientované na technicky zaměřené lidi.) Pro mě přínos FB je asi v těhle věcech:
veřejný obsahNo já FB používám výhradně jen na veřejný obsah. Jsou sice lidé, kteří mi píší na FB IM ale i tam se snažím mít na paměti (což se teda ne vždy povede...), že to fakt není soukromá komunikace a že to může kdykoliv kdokoliv číst. Ale jinak žádný obsah se sníženou viditelností netvořím, vše veřejné. Jsem i členem několika uzavřených skupin, ale i tam je tolik lidí, že je to taky v podstatě veřejné (a asi to je teda i veřejně vidět, jen to nečlenové nemohou komentovat). Co se týče toho organizování akcí, no já jsem dost paranoidní na to, abych dopředu "veřejně" oznámil kdy a na jak dlouho patrně nebudu doma. A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.
A s lidmi, kteří mají takový nápad to roztroubit do světa "učastním se akce a budou tak i tito další" jsem na FB udělal krátký proces. Akce se mají domlouvat pouze mezi účastníky a případné zveřejnění provést až po ukončení.Soukromou událost na FB vidí pouze ti pozvaní (což třeba v mém aktuálním případě dělá ~10 lidí) a nikdo jiný vůbec nevidí ani tu událost ani jestli se ji někdo účastní nebo ne ani nemají možnost ji "sdílet" nebo whatever, prostě se k tomu fakt dostanou jen ti pozvaní.
Sítě jako Facebook, Twitter či YouTube podle něj nedělají dostatečnou prevenci před šířením fake news, hate speech, harašení a propagandě na svých platformách.Zajímavé, on existuje nějaký zákon, který by jim něco takového nařizoval? Jestli ono to nebude spíš "tady je něco, na co my politici nemáme takový vliv, jaký bychom chtěli"
Rovněž je důležitá anonymita/pseudonymita, protože pokud stát neví, která fyzická osoba to je, nemůže ji za nepohodlné názory potrestat.S tou anonymitou bych to zase tak nepřeháněl, určitě ne hned v začátku. Podle mě je správné* podepsat své názory, stát (strašné slovo) si za tím, dokázat je obhájit slušným způsobem apod. Pokud je to anonymní výkřik, tak nemá zkrátka takovou váhu a navíc nikdy nevíš, zda to někdo neříkal z postranních důvodů. Podle mě je místo pro anonymizaci skutečně až ve chvíli, kdy za názor hrozí kulka do hlavy. V takových režimech jsou anonymní nástroje jistě přínosem, pokud jsou ovšem používány pro pravdivé informování o stavu v takové společnosti nebo režimu. Ani tady příliš nepomůžou výkřiky, které nejsou pravdivé. *) Jako jak jinak chceš budovat slušnou občanskou společnost, pokud budou všichni anonymní a Tonda nebude vědět, že stejné názory má i Karel odvedle, se kterým se na anonymních fórech vlastně shoduje? Prostě podle mého přesvědčení je potřeba anonymitu používat skutečně jen ve výjimečných případech a snažit se dostat do stavu, kdy už nebude potřeba.
Proto jsem psal anonymita/pseudonymita. Na to, abys podpořil nějaký názor autoritou svojí osoby, není potřeba, aby ostatní znali tvoji fyzickou identitu – stačí, aby si dokázali daný výrok/názor spojit s tvými dřívějšími projevy a dát si ho do kontextu. Naopak na tom internetu je mnohem užitečnější znát ten internetový pseudonym než znát občanské jméno a bydliště – např. komentář, který psal uživatel Heron pro mě má větší váhu než komentář, který psal např. Jan Zahradník z Frýdku-Místku registrovaný pod číslem 197611, který se nechal ověřit doporučeným dopisem a SMSkou a který o sobě vyžvanil i jméno babičky za svobodna a přiložil fotokopii vysvědčení ze základky.
Podpis beru jako součást projevu – stejně jako jazyk, styl nebo formu – a je na autorovi, jak a jestli se podepíše, jak moc propojí daný výrok se svojí internetovou nebo dokonce fyzickou identitou. A právo ostatních zase je, číst, co jim vyhovuje a přisuzovat tomu váhu i podle toho jak a kdo to podepsal – např. můžou zcela ignorovat anonymní příspěvky nebo příspěvky od neznámých pseudonymů. Různé druhy podpisu mají svoje výhody a nevýhody a nemyslím si, že by měla existovat nějaká obecná norma, jak se to má dělat.
pravděpodobnost, že ti někdo reportuje bug je na Githubu násobně vyšší než na nějakém self-hosted řešeníA není to spíš jeho problém? Založit ticket v self-hosted Bugzille nebo poslat bugreport mailem fakt není o moc složitější než založit issue na GitHubu. Pokud mu to nestojí za to, ať si klidně dál používá zabugovaný software, nebo najde nějakou alternativu. FOSS přece člověk píše zpravidla hlavně pro sebe a je jeho dobrou vůlí dávat to zdarma k dispozici ostatním. Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut? Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod. Kdyby se GitHub používal opravdu jen jako hosting pro git repozitáře, přičemž přechod na jinou službu by spočíval jen v nahrazení URL repozitáře na webu za jinou, tak bych s tím tak velký problém neměl. Otázkou pak je, proč něco takového dělat, když hostovat repozitář lze i na vlastním serveru, a to naprosto triviálně. Navíc lze vytvořit i soukromý repozitář, aniž by za něj bylo třeba platit (jako na GitHubu). A máš nad tím kompletní kontrolu ty, ne třetí strana, která se snaží tvářit, že je hodná, ale vždy se bude orientovat především na finanční zisk; a i kdyby ji zatím vlastnil nějaký moralistický idealista, vše se může změnit se změnou vlastníka.
+1
Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém.
A teď si to spoj s tím, že státy dělají MITM útoky a podstrkávají uživatelům mallware. Pokud jediný kontakt na autora softwaru, který máš, je URL na GitHubu a nemáš ani otisky jeho GPG veřejných klíčů, tak vládě stačí zatlačit na jednu firmu a může uživatelům okamžitě distribuovat škodlivý software. Neříkám, že napadnout libovolného poskytovatele domén a hostingu nejde – jasně, že to jde, ale těch poskytovatelů jsou spousty, mají různou míru (ne)ochoty spolupracovat a různou míru odvahy dát o tom svinstvu vědět veřejnosti. Kdežto, když je všechno v jednom centru, u jednoho subjektu, tak to má útočník mnohem jednodušší a šance na odhalení se snižuje.
Málo. Ale pointa byla v tom, že když je něco centralizované, je to snáze napadnutelné a snáze se dá útok utajit, než když by se útočník měl „dohodnout“ se spoustou malých subjektů – u nich je větší pravděpodobnost, že někdo z nich o útoku alespoň řekne veřejnosti.
V té velké korporaci o tom může vědět třeba jen pár lidí – zatímco většina zaměstnanců vůbec nic netuší (pro ně to jsou jen nějaké automatizované procesy, uzly v síti nebo krabice v serverovně, kam nemají přístup – ale na tom není nic divného, protože v korporaci je spousta míst, kam nemají přístup). Kdežto v té malé firmě/organizaci o tom bude vědět taky jen pár lidí, ale tam těch „pár lidí“ = třeba polovina nebo i většina zaměstnanců. A v celkovém součtu je těch lidí spousta, protože malých firem/organizací bys musel napadnout mnohem víc než velkých korporací provozujících centralizované služby, abys dosáhl stejného výsledku.
Další věc je, že korporace má hodně co ztratit (např. se přijde na to, že jejich „daňové optimalizace“ jsou nelegální a je potřeba doplatit spoustu peněz, nebo nedostanou vládní zakázky, nebo se přijme nějaký zákon, který je poškodí…), zatímco malá firma toho tolik nemá (přinejhorším1 zkrachují a nechají se někde zaměstnat a taky se nebudou mít špatně) a naopak tam je šance něco získat – zviditelnit se na odhalení vládních zločinů, získat tím jméno a pak (resp. před tím) třeba prchnout za hranice.
[1] taky by mohlo dojít na fyzickou likvidaci – ale pokud by např. v nějaké zemi začali ve velkém umírat provozovatelé hostingu nebo by např. velké procento z nich „mělo nehodu“ tak by si toho veřejnost všimla
Ona by to hlavně neměla být alternativní služba. Měla by to být vhodná svobodná implementace (v tomto případě verzovací systém + něco navíc), kterou si vývojářské týmy budou moci běžně provozovat na svých serverech. A k tomu nějaká federace identit (ať už SAML IdP nebo OpenID nebo ta tvoje identita může vycházet z tvého veřejného klíče) a pak nějaký standardizovaný formát, ve kterém bys mohl publikovat svůj profil – např. jsem přemýšlel o XML formátu, ve kterém bys mohl zveřejnit informace o sobě, kontakty, svoje úspěchy (odkazy na tebou nahlášené chyby, implementované funkce, opravy…), reference a hodnocení ostatních (např. oblíbené programy, vývojáři, od kterých ses něco naučil, přínosní uživatelé…). Každý by tenhle soubor zveřejnil na svém serveru nebo na serveru své komunity a celé by se to nějak indexovalo, ideálně P2P vyhledávačem (YaCy?).
Ostatně, to elitářství, o kterém se zmiňuješ dál, je zcela na místě: Jak kvalitní bug report lze očekávat od člověka, co si neumí vyhledat/zjistit/přečíst, jak reportovat bugy, a obětovat tomu pár minut?O tomhle to právě vůbec není. Zrovna dnes jsem řešil bug ve foss programu, který tady nejspíš všichni znají. Řešil jsem to během pracovního dne. Mám toho na práci víc než dost a musim řešit spoustu vlastních problémů, takže to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří čas. A platí zde něco podobného jako v reakci na tu Frantovu stížnost na cenzuru Facebooku: Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím. Nehledě na to, že nikdo s tímto názorem zatím nepředložil důkaz, že bugreporty na self-hosted řešení jsou skutečně kvalitnější.
Osobně mě nejvíc děsí to, jak velká část FOSS světa je závislá na jediné službě. Ono není tak moc pravděpodobné, že by GitHub ze dne na den zmizel ze světa a dokonce by se dalo předpokládat, že projekt hostovaný na GitHubu bude (většinou) dostupný delší dobu než self-hosted projekt. Ale i tak by větší diverzifikace byla záhodná – tohle je prostě moc snadný cíl. Co by se stalo v případě nějakého většího výpadku? Spoustu menších projektů dnes nemá ani vlastní web, jen README hostované na GitHubu, což je obrovský problém. Mirrory mohou existovat, ale neexistuje žádný autoritativní zdroj, nikdo nebude schopen prokázat, že on je tím původním autorem daného projektu a tady ve vývoji pokračuje apod.Podobný problém má asi tak každý balíčkovací manažer. Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha. Nějak nevidim, co z toho. Na teoretické rovině s tebou souhlasim. A co dál? Pravděpodobně nic, nejspíše budeme oba spokojeně nadále GitHub... Nebo snad ne?
to, že mají issues na GitHubu mi ohromě usnadňuje práci a šetří časKolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?
Stále mi přijde, že má větší užitnou hodnotu, když o nějakém bugu mám nekvalitní bugreport, než když ten bugreport vůbec nemám a o chybě nevím.Nekvalitní bugreport může přidělat hodně práce. Mám s tím z práce bohaté zkušenosti (převážně z reportů od UIčkářů). Nedávno jsem se rozhodl, že už to prostě nebudu řešit, dokud nebude přiložen detailní popis, podle kterého to půjde zduplikovat (nebo nebude výslovně uvedeno, že není známo, jak to zduplikovat, protože se to projevuje jen občas).
Bez nějakého realistického nápadu, co s tím dělat, mi tohle připadá jako prázdná úvaha.Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.
Kolik času ti to ušetřilo oproti self-hosted řešení za předpokladu, že by nebyla vyžadována registrace, samotné založení issue by bylo srovnatelně komfortní a efektivně by jediný rozdíl byl v jiné URL (na kterou by vedl odkaz přímo z hlavní stránky projektu, nebylo by to nikde schované)?Ten rozdíl efektivně pouze v URL nikdy nebude např. z toho důvodu, že na GitHubu mi přijdou notifikace o tom, že majitej repa mi odpověděl na můj bugreport (což se o hodinu později stalo). (Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.)
Vždyť je zřejmé, co s tím dělat. Mít vlastní web (stačí pro člověka, nemusí to být nutně pro každý projektík zvlášť) a repozitář si hostovat taky ideálně sám. Na bugreporty u úplně malých one-man-show projektů stačí kontaktní e-mail, u větších projektů mailing list a u ještě větších projektů třeba tu Bugzillu, JIRU nebo jakýkoliv jiný ticketovací systém, pod kterým se dají vést diskuze.Zcela upřímně, kdyby ten projekt to měl nasazeno takhle nějak, tak jim tam dnes ten bugreport nejspíše nepošlu. Můžeš mě zažalovat nebo se pohoršovat nad tím, jak jsem hroznej a linej a kdesi cosi ... Ale to je tak celý. Plus navíc ten projekt by musel vynakládat úsilí a finance na udržování toho setupu, a přitom GitHub poskytně lepší hodnotu za mnohem menší námahu a peníze. Opět máš možnost se pohoršovat dosytosti. A opět to na praktické stránce věci nezmění vůbec nic.
Vyplnění emailu za účelem notifikace někomu na nějakej server se efektivně rovná registraci a nechce se mi to moc dělat.
Osobně k tomu používám jednoúčelové e-mailové adresy na vlastní doméně – jedna adresa slouží ke komunikaci jen s jedním subjektem a kdyby došlo např. ke spamování, můžu ji okamžitě zaříznout. Dá se to i automatizovat – e-mailové aliasy se můžou vytvářet dynamicky resp. nemusí být ani nikde uložené – jen popsané algoritmem – např. doménaDruhéStrany + "." + hash(tajnýKód, doménaDruhéStrany) + "@x.moje-doména.example.com"
. A ten tajnýKód
můžeš mít i v nějaké své aplikaci, takže pro přidání resp. vygenerování nového e-mailového aliasu ani nemusíš komunikovat se svým serverem (ten jen na základě algoritmu a sdíleného tajemství ověří, že daný alias je platný). Pokud by náhodou došlo k vyzrazení klíče, uděláš z dosud použitých aliasů (na které přišel nějaký e-mail) klasické uložené aliasy a nové začneš vydávat na základě nového klíče.
Mailinator nebo podobné služby taky občas používám, ale to je jiný případ. To, co jsem popisoval, slouží ke spolehlivému doručování zpráv (třeba i za několik let, kdy už ta anonymní služba nemusí ani existovat), které nemají být veřejné (v rámci možností e-mailu). Cílem je, abych mohl sledovat, jak ostatní nakládají s mými osobními údaji a abych mohl snadno zablokovat případný spam.
Mám několik menších projektů, které bych mohl zveřejnit. Je to pro mě extra práce, protože to jsou často bastly dělané na míru pro mě. Ve stávajícím stavu se mi to moc nechce zveřejňovat – cítil bych silné nutkání projít a začistit zdrojový kód (možná to i celé zrefactorovat), doplnit dokumentaci, pořádně to dootestovat a podobně.Taky mám všelijaké takové, spíš většinou šuplíkové napůl nedokončené projekty ... Asi ti k tomu nic moc moudrého neporadim, záleží případ od případu a jak moc se ti chce / nechce to zveřejňovat. Ale v každém případě bych to nebral moc vážně. Když se podíváš, co jsou dnes lidi schopní zveřejnit za "projekty" - třeba JavaScriptové knihovny, které mají logo, baterii integračních testů a dokumentaci, to všechno jen kvůli třeba 50 řádkám reálného kódu* ... to pak zjistíš, že seš nejspíš úplně v pohodě i s nerefaktorovaným kódem. *) Něldy ani to ne, viz třeba tady.
Navíc ty sám připouštíš, že kdybys měl bug reportovat někam jinam než na GitHub, tak bys to vzdal.To zas ne. Tam šlo o ten kontext - byl jsem uprostřed pracovního dne, byl rozbitý build, potřeboval jsem rychle vyřešit problémy... Ve chvílích, kdy je víc klid a mam víc času jsem ochoten reportovat i jinam
To je takové systematičtější, ale je fakt, že pokud to má psát člověk z hlavy, tak si spíš vzpomene na to slovo a zbytek doplní mu bash completion.
git gui
" rozdělím na jednotlivé commity (které lze pak ještě dodatečně upravovat pomocí "git rebase -i
").
Je ale pravda, že větší počet commitů se hůř rebasuje, může se stát, že v jednom commitu člověk řeší konflikty jen proto, aby v následujícím úplně zmizely ...
To se sice stát může, ale až tak časté to není. Osobně radši dělám rebase série s jemnější granularitou, protože když na mne vypadne spousta konfliktů najednou, působí to na mne trochu depresivně a demotivačně. Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.
zpětně rozdělovat jeden WIP commit na více dílčích a tím víceméně psát fiktivní historii mi nepřijde úplně smysluplný
Nemyslel jsem tím fiktivní historii, ale rozdělení jedno monstercommitu na více logicky oddělených změn. Příklad viz třeba tady série ba3eb1a44b12..9fb1a27800d0
(normálně mívám commit message sdílnější, ale snažil jsem se přizpůsobit zvyklostem projektu). Sice by se to dalo sloučit do jednoho commitu "add IPv6 support", ale jsem přesvědčen, že takhle rozdělené je to mnohem přehlednější.
Navíc v rámci malého commitu řešícího jednoduchou izolovanou změnu je pro mne snazší udržet si přehled. Ale asi je to věc vkusu.no nevim, jestli jen vkusu. Me velke commity prijdou dost spatne z toho duvodu, ze delat review pull requestu, kde se meni kod treba ve 200 souborech (a uz jsem videl i horsi) je peklo a sance, ze se neco prehledne je podstatne vetsi, nez kdyz je to cleneno do mensich commitu. A i pokud je ten, kdo dela review je natolik schopny se koncentrovat, ze mu mu zadna chybu neunikne, tak tim urcite stravi o dost vic casu. Dalsi vec je, ze pokud se delaji backporty treba do nejake LTS vetve, tak se obcast stava, ze v ramci vyvoje nove funkcionality je upravena nejaka stavajici, kde se casem ukaze, ze tato jeji uprava je potreba backportovat. Udelat cherry-pick daneho commitu je bezpochyby mnohem jednodussi nez to dolovat z obrovskeho commitu. Takze IMHO clenit commity podle (pokud mozno malych) ucelenych logickych celku je vyhodnejsi jak kvuli mensi nachylnosti k chybam, tak celkove snadnejsi udrzovaletnosti kodu.
kde se meni kod treba ve 200 souborecha ten, kdo to cele navrhoval, sef projektu a vsichni ti ostatni, co jsou zodpovedni za tu architekturu takoveho software - ti dostanou vypoved na hodinu a nebo smeji zustat celou vypovedni dobu?
ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořilJaký je tvůj usecase pro větvě, které nejsou
master
, ale existují dlouhodobě? Osobně když vytvořim větev, předpokládám u ní pokudmožno krátkou dobu trvání. V podstatě čím kratší, tím lépe. Případně si umím představit něco jako master
+ dev
nebo master
+ stable
nebo něco takového, některé projekty to tak mají.
Náhodné / ad-hoc větve, které ale existují dlouhodobě, mi čistě osobně a subjektivně nepřijdou jako dobrý nápad. Je to jenom moje 0.2$, můžeš samozřejmě neoushlasit a dělat si s gitem co chceš...
Jen tak pro zajímavost - kolik z vás si hlídá jeho prostřednictvím změny konfigurace?V gitu mývám všechno možné...
Vždy se najdou výjimky. Já mám třeba v gitu spoustu větví, které přidávají nějaký specifický tracing určený pro konkrétní bug. Ty se hodí zachovat, protože později můžu chtít použít podobný nebo dokonce stejný patch a nemusím ho tak psát znovu.
No a potom existují hodně specifické repozitáře jako např. tehnle, kde se vlastně všechno zajímavé odehrává mimo master branch.
Já jsem nepsal že mám větší množství větví s nedokončenou prací, ale že mám problém si po nějakém čase rozpomenout, proč jsem vlastně nějakou tu větev vytvořil. Což nesouvisí ani se jménem, ani s počtem větví.A co ti brání takovou větev prostě zahodit? Zjevně už není potřeba. (Leda by na ni vedl odkaz z nějakého úkolovníčku, ale to by začínala číslem issue.)
Někdo si toho možná všimne a třeba mu to bude i ku prospěchu.Ovšem to asi nebude případ těch, co nevšimli ani toho, že jsem se o nich zmínil. Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí. Spolupráce na projektu je podmíněna tím, že se v prvé řadě stanoví jak takové workflow bude vypadat, důsledně se pak dodržuje a nově příchozí ho pak buď akceptuje (a k projektu se přidá) nebo si udělá fork a nastaví si vlastní workflow pravidla. A právě v situaci, kdy chci zkombinovat věci které mají různá workflow do jednoho projektu, se může hodit onen lokální popis. Jinak ta diskuze je téměř od samého počátku mimo mísu. Relevantní byla tak maximálně poznámka, že k přepnutí větve s rozdělanou prací lze použít příkaz
stash
. Následující dohady, jestli používat gihub, nebo něco jiného. Nebo jak si pojmenovávat větve. Jsou už na úrovni hospodského dohadování. A tomu také odpovídají i moje reakce v tomto vlákně.
Ruku na srdce - diskuze na abclinuxu jsou sice zdrojem zajímavých podnětů, ale nevěřím tomu, že by měly pozitivní vliv na způsob práce diskutérů. Jeden vedle druhého tady píše jak to dělá on, a jak je to podle něj správné, aniž by vůbec brali v potaz, že jejich specifické workflow těm ostatním vyhovovat nemusí.Podle sebe soudím tebe...
Tiskni
Sdílej: