A bude hůř

6.4.2016 13:06 | Přečteno: 2301× | Za vším hledej Linux

Nevím jestli si toho všimnul i někdo jiný, ale s masovým rozšířením gitu začala éra totálního úpadku štábní kultury při uvolňování aktualizovaných verzí software, což sebou nejspíš stáhne do sraček i linuxové distribuce, které za sebou nemají týmy placených specialistů co mají hrabání se v software jako svou pracovní náplň. V čem tkví podstata problému.

Díky moderním verzovacím systémům, jako je git se stalo verzování velice pohodlným. Dříve, než byla nějaká verze uvolněná, předcházel jejímu vydání testovací proces, který měl za cíl ověřit, že je vše skutečně funkční. Dnes na to nikdo nemá čas. Změny se totiž v repozitářích objevují tak rychle, že co platilo včera již platit nemusí. A každý zásah do kódu může znamenat jak zavlečení nové chyby, tak změnu chování aplikace, která se za určitých okolností může ukázat jako fatální.

Není sporu o tom, že původní systém založený na tarballech byl pro vývojáře poněkud nepohodlný - kdo by se chtěl zpětně babrat v kódu a hledat opravu, když se kód připravovaný pro další vydání změnil natolik, že v něm už oznámená chyba ani nemusí existovat.

Verzovací systémy to značně ulehčují. Není nic snazšího, než kód, který má být považován za stabilní, umístit do nové věteve. Každý ať si pak z repozitáře klonuje co chce. Opravy nalezených chyb jsou v takovém případě mnohem snazší. Jenže to má háček.

Pro vývojáře, který se ve svém repozitáři hrabe dnes a denně je jasné jak facka, kterou větev lze považovat za stabilní a která je vývojová. Jenže co lidé, kteří sestavují distribuční balíky?

Dříve to bylo zcela jasné. Vydaný balíček měl své číslo verze a z čísla subverze bylo ihned jasné, který kód je novější. Jenže dnes? Opravy se mastí rovnou do příslušné větve a kód se čas od času otaguje více či méně smysluplným číslem subverze. Potud ok.

Jenže pokud je aplikace sestavena z aktuálního kódu, nic takového nemá. V lepším případě sebou nese hash aktuálního commitu. Jenže z toho lze jen stěží poznat ze které větve pochází.

V případě komplexních softwarových balíků, které se skládají s více komponent tak postupně vzniká větší a větší bordel, neboť pozvolna přestává být jasné z jakých verzí byly vlastně sestaveny a jaké podmínky musí být splněny aby vše fungovalo jak má. A pokud se objeví chyba tak vyvstávají zcela zásadní otázky:

• Čím je chyba způsobena?
• Je to problém distribučního balíku, nebo aplikace jako takové?
• S kým to mohu konzultovat? Komu mám o tom napsat?

Většina lidí v současné době má problém skutečnou příčinu chyby vůbec odhalit. Vývoj díky verzovacím systémům je tak prudký, že věci rozbíjejí na jiných místech dřív, než se stačí opravovat chyby předchozí. Není divu, že pak nastávají situace jakou popisuje aktuální zprávička o dění kolem XscreenSaveru v Debianu. Není v silách maintainerů aby sledovali každý prd. A v případě komponent, které závisí na hromadě dalšího software to zkrátka nejsou schopni zvládat.

Já mám svůj vlastní příklad takového problematického distribučního balíku, kterému se principiálně vyhýbám - Pacemaker. Ne proto, že by ten distribuční balík nebyl funkční, ale nemohu si zkrátka dovolit riskovat rozbití funkčního clusteru kvůli obyčejné aktualizace. Cluster není desktop. Když se rozběhá, tak musí běžet a to i řadu let - pak již není prostor na hledání příčiny toho proč něco nefunguje.

Pacemaker netvoří jen jedna komponenta. Jeho funkcionalita je závislá na celé řadě komponent, které mají své vlastní vývojové repozitáře. A stačí jen drobná změna v chování některé z nich k tomu, aby vaše skvělá konfigurace přestala pro aktualizaci fungovat tak jak má. Jenže Pacemaker je komplexní software, jehož testování není jednoduché - ne každý má k dispozici stroje, na kterých by si mohl vyzkoušet všechny možné i nemožné situace ke kterým může dojít. Uživatelská základna není tak široká, abyste měli s kým váš problém konzultovat a hledání příčiny proč něco najednou přestalo fungovat žere čas, který vám nikdo nezaplatí.

Řeším tedy situaci tím, že používám vlastní binární balíček u kterého mám 100% jistotu že funguje jak má. To jsem se takhle před dvěma lety strefil do šťastného období, kdy zrovna všechno fungovalo jak má. Distribuční balík je v podstatě také funkční, i verze sestavená z aktuálních zdrojových kódů, ale bohužel se nechovají korektně a já nemám čas zjišťovat, zda-li je problém v tom, že chybí něco v konfiguraci, nebo je někde nějaký bug.

       

Komentáře

[Michal Kubeček]

Přijde mi zavádějící tohle připisovat gitu a jeho rozšíření. To, jakým způsobem projekt (ne)označuje, (ne)testuje a (ne)vydává nové verze, je IMHO dáno především náturou a způsobem uvažování jeho vývojářů. Podle mých zkušeností projekty, které buď přešly na git buď z CVS/SVN nebo které předtím ani veřejně přístupný VCS repozitář, svou release policy obvykle nijak zásadně nezměnily.

Git může řadu postupů usnadnit, ale pokud vývojář např. míchá nesouvisející změny dohromady nebo nepíše smysluplné commit message, git ho k tomu sám o sobě nedonutí. A s polikou pro vydávání a označování verzí je to IMHO úplně stejné. Z hlavy mne napadá třeba mplayer, který měl dlouhou dobu jen jeden prastarý (pre-)release a denní snapshoty, a to ještě předtím, než byl k dispozici veřejný VCS repozitář.

[Aleš Kapica]

Samozřejmě že to není problém gitu jako takového. To je pouze nástroj. Podstata problému je v tom, že tzv. "informační technologie" sebou nesou všeobecný úpadek oné štábní kultury, která spočívá v tom že se dodržují nějaká pravidla.

Předpokládám, že vám neuniklo, jak postupně stále více více serou na nějaká pravidla informační média - a od toho to začíná. Pokud někdo není schopen dodržovat psaní y/i, udržet slovosled a rozlišit mužský a ženský rod. Potíž je v tom, že zvolna klesají nároky. Takže dnešní děti už nejsou schopny zachovávat ani to, k čemu za mých dětských let donutilo okolí mne. A to je co říct.

[pravda-boli]

Pamatam si rok 1989 mal som dva roky, vladli nam komunisti a bolo to pekne obdobie. Vsetci mali pracu, nikto nebol hladny a vsetko bolo lacnejsie. Zmrzlina stala korunu, teraz stoji euro.

Dnes vsade tucne jedla, hypermarkety su plne nezdravych jedal, vsade sa predavaju hamburgery, kebaby a pizza z ktorych sa pribera. Ludia uz nemaju ani kam chodit vsade len nakupne centra. Vsetci maju iPhony, iPady a Androidy, ktore ich ozaruju a potom maju nadory na mozgu. Otcovia rodin miesto toho aby vychovavali deti si vydrziavaju o 20 rokov mladsie dievcata. Vsetko zlo prislo z USA a NATO. Imigranti znasilnuju zeny a ukrajinci vrazdia Rusov.

Jedine v Rusku je dobre lebo tam to dal do poriadku Putin, tam maju vsetci pracu lebo povedali nie zapadu.

[Laci]

Ladislav Kuc spáchal bombový útok, ako aj ďalšie činy vrátane výroby výbušnín, nedovoleného ozbrojovania, vydierania či zastrašovania obyvateľstva a predstaviteľov štátu. K výbuchu podomácky vyrobenej bomby, uloženej v odpadkovom koši, došlo podvečer pri rýchlom občerstvení 28. decembra 2011 na košickej Ulici protifašistických bojovníkov.

Zhodou šťastných okolností nikto neutrpel zranenie, explózia spôsobila len materiálne škody. Kuc zaslal aj listové bomby veterinárnemu lekárovi, ktorý v Košiciach vykonával asanačnú službu, ako aj na Univerzitu veterinárneho lekárstva. Ani tie si našťastie nevyžiadali ľudské obete. Odsúdený tieto skutky páchal v mene ochrany životov psov.

[Tomas]

vývojář např. míchá nesouvisející změny

to on existuje nejaky system, ktery nesouvisejici zmeny rozezna? Jak?

[Michal Kubeček]

Jediný takový systém, který znám, je přísný a důsledný maintainer. :-)

Ale to byla podstata mého příspěvku: git může workflow usnadnit a dobře vedenému projektu pomoci. Ale pokud vývojáři nemají disciplínu a na "štábní kulturu" kašlou, nepomůže takovému projektu sebelepší VCS.

[ChronicPain]

Ale na druhou stranu je treba imho dodrzovat a vymahat podminky, ktere autor (drzitel prav) pro uziti dila stanovil, a je lhostejne, zda dilem je svobodny software nebo novy film.

[Grunt]

Řeším jednoduše: Software u kterého to vyloženě potřebuju si udržuju v /opt větvi (týká se to většinou mplayeru/mpv či nějakého jiného multimediálniho softu, ale teď jsem zkoušel i vlastní gcc), kompiluju si do něj co uznám za vhodné, linkuju ho staticky proti verzím knihoven které já uznám za vhodné. Když mi něco nefunguje, vždy zkusím ještě distribuční verzi. Spousta let k plné spokojenosti (teda krom toho že po pár letech v tom začne být obrovský bordel a nejvíc místa na disku sežere adresář /usr/src).

[Aleš Kapica]

Spousta let k plné spokojenosti (teda krom toho že po pár letech v tom začne být obrovský bordel a nejvíc místa na disku sežere adresář /usr/src).

A právě o tom to je. Pokud si někdo šmudlá dva tři víceméně podobné stroje, tak je to ještě únosné, ale pokud je těch strojů více, každý pes jiná ves. Každý s jiným účelem, v různých lokalitách, s různou konfigurací - pak se stává situace neúnosnou a bez nástrojů jako Puppet, Chief apod. totálně nezvladatelnou.

Po pravdě řečeno - kdybych nezvolil již před lety strategii jakou mám (kritické balíky vlastní provenience, základní konfigurace udržované přes Puppet a sledované přes git) tak už bych byl v pytli.

[Grunt]

Jakože vlastní balíky z pozice administrátora a třeba i s více lokalitami? Když už nic tak je to aspoň zajímavá filosofická otázka. Já jsem něco takového ještě neviděl.

[Grunt]

Pokud si někdo šmudlá dva tři víceméně podobné stroje, tak je to ještě únosné,

No moc ne. Hele a dělá si někdo vlastní balíčky nebo dokonce provozuje vlastí repositář?

[Michal Kubeček]

Hele a dělá si někdo vlastní balíčky nebo dokonce provozuje vlastí repositář?

Třeba já. Dokonce několik.

[Grunt]

Jaký tool? A ty balíčky se instalují kam? Klasicky do /usr nebo se to dá držet i s distribučníma verzema?

[Michal Kubeček]

openSUSE Build Service - výhodou je, že pokud u projektu povolím publikování, výsledné balíčky jsou k dispozici přes URL, které můžu přímo předat "zypper addrepo" a funguje pak stejně jako kterýkoli jiný repozitář.

Až na výjimky (např. snapshoty Firefoxu, u kterých chci, aby nekolidovaly s distribučním balíčkem) se snažím držet FHS a dalších distribučních zvyklostí.

[Aleš Kapica]

Slyšel jste někdy o dpkg? Fakt dobrý. Vyzkoušejte.

[Grunt]

Na rpm distru?

[Grunt]

Ale jinak vím že existoval nástroj který přímo ze zdrojáků namísto make install dělal přímo buď DEB nebo RPM balíčky (výběr dle switche), bohužel mi už vypadl název z hlavy.

[Michal Kubeček]

checkinstall - ale to je spíš jen taková nouzová berlička pro toho, kdo za žádnou cenu nechce vědět nic o vytváření balíčků, ale chce mít možnost snadno odinstalovat něco, co si přeloží přímo z upstreamových zdrojáků.

[Grunt]

Yup. To je myslím ono. Díky. Vím proč to sem píšu

[Pavel Píša]

Buď si lze udělat kompletní repo, jako máme třeba pro vlastní buildy cross-kompilátorů. Něco o použití a instalaci těch kompilátorů zde https://rtime.felk.cvut.cz/hw/index.php/Cross_compilers. O použití vání Debian repa na našem serveru https://rtime.felk.cvut.cz/wiki/index.php/Debian_packages_repository a obecně, podle čeho to bylo postavené http://blog.jonliv.es/blog/2011/04/26/creating-your-own-signed-apt-repository-and-debian-packages/

Pokud se jedná o použití jen o použití na jednotlivém počítači nebo o nutnost instalace vybuildovaných balíčků závislostí během kompilace než je odzkoušené, že má smysl balíčky poslat do repa, tak je nejjednodušší provést

mkdir -p /usr/local/debs
echo "deb file:/usr/local/debs unstable main" >/etc/apt/sources.list.d/local-debs.list
cd /usr/local/debs
mkdir -p pool
mkdir -p dists/unstable/main/binary-amd64
mkdir -p dists/unstable/main/binary-i386
touch override

Pak si vybuildovat balíky, s tím, že ve vastních mám control třeba nastavené unstable, ale není nutností. Balík, pokud je vybuildovaný třeba před dpkg-buildpackage dám například do /usr/local/debs/pool/fpc, nakopíruji všechny vygenerované *.deb a často si tam schovám i zdrojáky v TARu, abych to měl u sebe a pak provedu

umask 022 ARCHS="amd64 i386" OVERRIDE=override DISTRIBUTION=unstable cd /usr/local/debs || exit 1 for ARCH in $ARCHS ; do dpkg-scanpackages -a${ARCH} pool ${OVERRIDE} \ >dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages gzip -c dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages \ >dists/${DISTRIBUTION}/main/binary-${ARCH}/Packages.gz done apt-ftparchive -c conf/apt-${DISTRIBUTION}-rtime-release.conf \ release dists/${DISTRIBUTION} >dists/${DISTRIBUTION}/Release

A pak již klasicky

aptitude update
aptitude install jmeno-baliku

Většinou tedy jdu spíš přes interaktivní režim a přes "l" vyberu balík a pak vidím, jakou verzi nabízí distribuce (její verze bude podle nastavení distribuce default) a jaké alternativní verzi mám k dispozici včetně té mé a tu si vyberu a nainstaluji. Pokud později distribuce přejde na novější verzi, než mám lokálně přidanou, tak se mi i v updatech automaticky objeví, ale updaty distribuce, které jsou mezi staršími verzemi než je ta moje se automaticky nenabízí. V aptitude si ale kdykoliv mohu verzi vybrat a přeinstalovat mezi nabídkou různých repozitářů, jsou vidět jen aktuální verze z repositářů, vracet se ke starším bez jejich uložení v local nejde a mít v jednom local více verzí pod stejným jménem balíku také povede k tomu, že bude nabízený jen ten nejnovější. Alespoň takto to umím já, možná je nějaká alternativa.

[snajpa]

V podstate kdokoliv, kdo to se spravou serveru mysli trochu vic vazne. Vlastne mne nenapada nikdo, pokud se budem bavit o lidech, co opravdu vedi, co delaji, kdo by nemel vlastni repa s opatchovanyma vecma.

[rADOn]

Obvinovat git je v podstate vytahovani stare hadky o katedrale a trzisti. Kdyby to bylo jen rychlym vyvojem, tak by gentoo byla nejrozbitejsi distribuce vubec.

[Odin1918]

Nejak nevidim rozdil mezi tim, kdyz nejaka revize otagovana a kdyz je z nejake revize vyroben tarball. Ano, rozdil zde je, a to ten, ze se tarball pouziva daleko vice spatne. Pokud nekdo udela balicek z vyvojove vetve a pak se divi, ze mu to poradne nefunguje, je to jeho problem. Prijde mi, ze za nefunkcni balicky opravdu nemuze git, ale spise ten, kdo vybiral revizi k balickovani a balicek z ni udelal.

[Jindra]

Kdyz nejake problematice nerozumite, tak neni nutne, abyste se k tomu vyjadroval. Zustante klidne u zdravotnictvi a soukromeho skolstvi.

[Odin1918]

Velevazeny Jindro, tak mne prosim poucte. Jak souvisi nefunkcni obsah balicku s tim, ze k verzovani zdrojoveho kodu onoho programu byl pouzit git? Jak je pro funkcnost ci miru chyb a bugu dulezite to, jaky verzovaci system je ci dokonce neni pouzit?

[User682]

No a ja bych navrhoval, abychom se vratili k CVS a disketam, nebot pak bude kvalita software lepsi.

No a ted vazne:

Asi jste chtel rici, ze je nejaka souvislosti mezi tim, jak se vylepsuji verzovaci systemy a kvalitou software. Ale je minimalni. A vlastne nedulezita velicina.

Testovani a SCM systemy jsou 2 rozdilne veci.

Pracuju jako programator na bazi kodu o velikosti asi 1M radku zdrojaku a denne to dela transkace za 10-100vky mega. Fakt to neni tak jednoduchy, jak to vypada. Ze si to jen tak opravite a udelate. Mozna i otestujete. A mozna to pojede. To neni webik s fotogalerii, kde si hned upravite, co chcete a vite, jeste vubec v kterym modulu to je a zda je vubec Vas.

To na co narazite je testovani. Nekdo ho ale musi udelat, udrzovat. Asi i zaplatit.

Ono to co pisete neni tak jednoduchy. Zkuste delat balickovace nekde v Novelu ci podobne a zjistite, jak to chodi. Pripadne programovat neco fakt vetsiho. Nebo profi testera. Tusim, ze Vy asi jednom adminujete a pisete blogy. Mozna se to zmenilo, co se tyce IT kvalifikace. Pripadne si pro srandu rozjedte poradne Jenkins s par desitkama/stovkou modulu. To je zajimava zkusenost pro admina.

gf

[Aleš Kapica]

Vážený pane, až mi nádor zatlačí na podvěsek mozkový, tak se začnu možná zaobírat rpm sragorama, ale zatím jsem při smyslech, takže mi Debian a jeho nástroje bohatě stačí.

[Svíčka]

Podvěsek mozkový není součást vyšších kognitivních funkcí, nebyl by nádor v těch místech spíš neblahý pro nerozumové funkce?

Třeba u mozečku/mozkového kmene to ohrožuje smysly, ovládání svalů, citlivost a vitální funkce, ale ne intelekt/osobnost. Každopádně o tomhle radši nežertovat, to bych nepřál ani Putainovi (i když sráč hodně pokouší).

[R]

Git vznikol povodne na vyvoj Linuxu (kernelu). Nemam pocit, ze by kernel nikto netestoval a neoznacoval stabilne verzie.

[Ondřej Kubečka]

Když je chabý (žádný) Software Configuration Management, tak je v podstatě jenom otázkou času, než se vývoj rozklíží. Ale tenhle zápisek mi přijde trochu od věci, protože Git (jako každý správce kódu a "verzovač") je naopak naprosto zásadní pomocník k tomu dělat to správně.

[Emil Zátopek]

… i dělat to špatně.

[pavlix]

Nemyslím si. Git je jenom nástroj. Možná je jednodušší a použitelnější než byly předchozí VCS, ale neviděl bych to jako chybu.

[Odin1918]

+10^6

Imho nefunkcnost opravdu s gitem nesouvisi.

[Josef Kufner]

Tohle chce udělat osvětu okolo verzování, tagování, vývojových cyklech a souvisejících věcech. Git je dobrý nástroj, ale nevynucuje si přesné workflow, ani nevede vývojáře za ručičku. To je potřeba dodat vedle.

[Tomáš]

Já tam četl GIFu a nějak mi to nedávalo smysl. I když animovaný GIF stojí za úpadkem webu, protože i dnes si stále hodně lidé myslí, že animovaný GIF je lepší nápad, než video.

Na GIT bych nic nesváděl, prostě to je jako všude jinde. Ignorance a nevděk světel vládne, programuje čím dál tím víc ťulpasů, počet odborníků zůstává stejný, ale holt nejsou tak vidět.

Obecně bych řekl, že kvalitního člověka kvalitním nástrojem nenahradíš. Je tam velká synergie, ale blbec bude dál dělat blbosti i s kvalitním nástrojem.

[Aleš Kapica]

Podstata problému je jinde. A to, že vydávací cyklus nových verzí je tak je tak krátký že to nikdo nestíhá pořádně testovat. Takže se mnohdy dostává do produkčního nasazení software, který ve skutečnosti nikdo pořádně nevyzkoušel jen proto, že jde o aktuální "stabilní" verzi.

[Odin1918]

A za to vsechno muze git

[pavlix]

To mi nedělej, málem jsem smíchy spadl z gauče.

Mimochodem, kdysi mi Aleš psal, že ví, kde bydlím, a že by mi rád dal do držky. Naučil jsem s Gitem dost lidí, takže myslím, že by to měl už kvůli tomuto novému důvodu konečně realizovat. :D

[Aleš Kapica]

Jo. Zrovna včera jsem to ukazoval Maxovi

[pavlix]

Máš odkaz? :)

[Aleš Kapica]

Odkaz? Na co? Foto jak mu ukazuji prstem na barák kde bydlíš? To asi nepůjde. Nepatřím k lidem co by si při každém prdu dělali selfíčko. Byli jsme předtím na pivo a při čekání na tram na to přišla řeč.

[pavlix]

Myslel jsem na tu diskuzi.

[Aleš Kapica]

Ale né. To jsme si neporozuměli. Ta diskuze tenkrát měla svůj kontext. Nejsem zase tak krvežíznivý jak by se z ní mohlo zdát.

[pavlix]

Kontext si nepamatuju, asi mi nepřišel dostatečně významný. :)

[Aleš Kapica]

S gitem se to má jako s PHP. Dostupný a dovoluje prasit.

[Odin1918]

Kdo chce prasit, prasit bude, a je uplne jedno, zda pouziva git, nebo tarbally posilane mailem. PHP ma spoustu nedostatku, ale ty nejsou pricinou praseni, prasit lze ve vsech jazycich.

[pavlix]

PHP je podle mě jenom sociální experiment za účelem dokázat, že lze uplést z hovna bič. Začínalo to úplně špatným návrhem, který byl už tolikrát revidován, že je z toho dneska už jen programovací jazyk mnoha nepříjemných překvapení.

[Aleš Kapica]

Přesto poměrně rozšířený - i se slušnými implementacemi, ale většinou děsu běsu.

[pavlix]

S gitem se to má jako s PHP.

Asi tak jako se to s autem má jako s nohou. :)

[ChronicPain]

Firemni procesy se nedelaji jen tak a vy jako zamestnanec nemate a nemuzete mit dostatecne sirokou perspektivu na to, abyste se takto mohl rozhodovat z vlastni vule kvalifikovane. Neni to spise tim, ze mas obavy, ze lide, jako jsi ty sam, by v ciste kapitalismu posli hlady?

[Aleš Kapica]

Neni to spise tim, ze mas obavy, ze lide, jako jsi ty sam, by v ciste kapitalismu posli hlady?

To tedy rozhodně nemám. Lidé jako jsem já jsou totiž pro čisté kapitalisty jako ty slepice co jim nesou zlaté vejce. Sice se jim moc nechce sypat zobání, jenže bez něj nejsou ta vejce na kterých stojí jejich byznys.

Nedělám si iluze, ale kolik je v téhle zemi lidí co se hrabou v technologiích co já? 50? A to jsem možná přehnal. Ale co tam počítače. Je tolik jiných činností co člověk může dělat a mít z nich potěšení i obživu. Takže opravdu ne. Ale mezi uživit se a parazitovat na práci jiných je nebetyčný rozdíl.

[trekker.dk]

Já mám svůj vlastní příklad takového problematického distribučního balíku, kterému se principiálně vyhýbám - Pacemaker. Ne proto, že by ten distribuční balík nebyl funkční, ale nemohu si zkrátka dovolit riskovat rozbití funkčního clusteru kvůli obyčejné aktualizace. Cluster není desktop. Když se rozběhá, tak musí běžet a to i řadu let - pak již není prostor na hledání příčiny toho proč něco nefunguje.

Jen tak mimochodem - Pacemaker už je taky v jessie-backports. Ale automatický upgrade z wheezy na jessie prý fungovat nebude, takže už se těším, že budu mít co na práci

[ChronicPain]

Ja s ni nesouhlasim skoro v nicem, coz je prirozene kvuli ideologii, kterou oba vyznavame (kazdy jinou), ale je to zena a k zenam je treba chovat se slusne, i kdybychom je v dusi nenavideli (coz neni muj pripad, ja mam kazdou zenu rad), tak mne to ucil muj otec a na vychovu ja prikladam velky duraz. Nekomu xivot prodlouzi, ale na ukor toho, ktery to musi zaplatit ze svych dani, coz mu snizuje zivotni stesti, jelikoz sam fakt, ze musi nekomu cizimu neco platit je strasny, a take to, ze takto odevzdane penize by mohl vyuzit pro zkvalitneni sveho zivota (napr.

[x]

XScreenSaver není zrovna moc dobrý příklad, jeho autor nepoužívá VCS (alespoň ne veřejně), i když kódy verzí nahrál jeden z uživatelů na github.

Jinak ale zápisek nedává zas až tolik smysl, když se vezme v potaz, že git používá balíčkovací systém {Home,Linux}Brew, nebo distribuce Exherbo, Sta.li (zapadá jim to do toho, že není "bloated"), ze zavedených dister se ke stahování balíků přes git chystá třeba Gentoo.

[x]

Podle článku na matrix.ai naopak systémy, které umožňují adresování revize podle obsahu, mohou pomoci s reprodukovatelností buildů; vedle gitu jsou zmíněny Nix, Guix a idh.

[Aleš Kapica]

Předpokládám, že úsloví "Mnoho psů - zajícova smrt" jste pravděpodobně ještě nikdy neslyšel.

[x]

VCS nejsou jedním ze psů. Pokud se podaří zajícovi prchnout do bezpečí díky reprodukovatelným buildům, tím lépe.

[x]

To úsloví celkem vystihuje pravděpodobnější důvod, proč software stojí za houby: https://harmful.cat-v.org/Blog/2014/07/23/0/

[pavlix]

Your connection is not secure

[ChronicPain]

A ten pravej na to zase reaguje. Hospody, bary, restaurace i cajovny jsou vsak naprosto privatni zalezitost, do ktere stat nema mluvit.

[x]

Nicméně, něco pravdy na tom je - třeba gnunet si snaží vynucovat štábní kulturu používáním svn a ne gitu.

[pavlix]

třeba gnunet si snaží vynucovat štábní kulturu používáním svn a ne gitu.

Nikoliv. Tedy alespoň podle toho, co tam píšou.

First, we want to be open to new developes and make the learning curve as simple as possible.

A proto se člověk musí učit mnohem složitější nástroj namísto nástroje, který může během několika minut používat i pro vlastní projekty.

Sure, git does not prevent this, but it makes it too easy to keep code "private".

Tomu subversion nijak nezabrání a nejlepším důkazem je právě dále zmíněný git-svn.

Já chápu, že Git není svatý grál, je to jenom nástroj se svými výhodami i omezeními. Chápu i to, že lidé dají vědomě přednost jiným nástrojům. Ale obávám se, že subversion existuje pouze z historických důvodů a udržuje se pouze díky stávající user base.

[x]

Nikoliv. Tedy alespoň podle toho, co tam píšou.

Vyplývalo mi to právě z toho

Second, as a maintainer I want developers to commit ('push' in Git terminology) often, so we have an integrated version and run automated regression tests, portability analysis, static analysis tools, etc. on the code all the time. Sure, git does not prevent this, but it makes it too easy to keep code "private".

ale může být, že jde spíš hlavně o zvyk na svn.

[pavlix]

Jsem o tom přesvědčen. Ani neříkám, že je Git dokonalý, ale CVS/Subversion opravdu nepovažuju za řešení. Čím dřív to umře, tím líp pro všechny.

[deda.jabko]

Myslim, ze neni na miste obvinovat GIT, opravdovy problem je v:

Pacemaker netvoří jen jedna komponenta. Jeho funkcionalita je závislá na celé řadě komponent, které mají své vlastní vývojové repozitáře. A stačí jen drobná změna v chování některé z nich k tomu, aby vaše skvělá konfigurace přestala pro aktualizaci fungovat tak jak má

Ale souhlasim s tim, ze bude hur. Ale ne kvuli GITu, ale kvuli rezignaci na princip KISS u lidi, kteri se venuji infrastrukture, a snaham budovat obrovske molochy, kde neni jasne, co se deje uvnitr a co souvisi s cim.

[Aleš Kapica]

A v tom byla podstata sdělení. "Záporná" role verzovacích systémů je především v tom, že díky svým vlastnostem oddalují okamžik katarze, kdy vývojářům dojde že to je fakt neúnosné, a je třeba zvolnit. Jinak zcela reálně hrozí, že se ty jejich skvělé aplikace přestanou nasazovat.

[deda.jabko]

"Záporná" role verzovacích systémů je především v tom, že díky svým vlastnostem oddalují okamžik katarze

Verzovaci systemy verzuji, nic vic, nic min. Ze si nekdo zvoli proces vydavani verzi podle svych potreb, je bud jeho nebo tvuj problem, ne verzovaciho systemu.

FYI: Podstata meho sdeleni byla uplne jina. Tvuj problem je uz v samotnem Pacemakeru a v jeho (molochovite) architekture a implementaci a za to GIT opravdu nemuze. Pokud mas problem, ze dilci aktualizace neco rozbije, zvazoval bych poohlednuti se po jinem reseni.

[Aleš Kapica]

Koukám že pán je znalec. Očekával bych, že by z vás vypadla alespoň nějaká alternativa. Ovšem to bych chtěl asi moc.

[ChronicPain]

Vase nazory jsou jen dukazem toho, ze soucasna spolecnost ma mozek dokonale vymyty socialistickou propagandou (slabym je treba pomahat, zamestnavatele vas vykoristuji, musite v praci intrikovat pro zachovani mista, je treba donaset na druhe, a dalsi veci co jste predvedl) a jiz si nedokaze predstavit, jake by to bylo na svobodnem trhu. Ja s ni nesouhlasim skoro v nicem, coz je prirozene kvuli ideologii, kterou oba vyznavame (kazdy jinou), ale je to zena a k zenam je treba chovat se slusne, i kdybychom je v dusi nenavideli (coz neni muj pripad, ja mam kazdou zenu rad), tak mne to ucil muj otec a na vychovu ja prikladam velky duraz.

[Aleš Kapica]

Co furt máš ksakru s těmi ženskými? Si nějakou najdi, chovej se k ní jak chceš a neotravuj na tomhle webu.