Názory k článku
Debian se zatím proti AI nevyhrazuje

> Co jsem se díval (8 let nazpět) někdy v době Python Django, tak tohle je tak na 10 řádků. A to ani nemluvím o Ruby On Rails.

Ano, 10 řádků furt opakujícího-se kódu kde se liší názvy class a proměných, které může napsat AI

> Knihovna na B-Tree se napíše jednou, už byla napsaná v C někdy v roce 1980. Proč AI?

Když jsme potřebovali naposledy řešit btree v PHP, nic na to neexistovalo ... Aspoň co by splňovalo požadavky.

> Tohle je moje moc oblíbené téma. Vymyslí se stopadesátá vrstva... Která má zjednodušit práci.
CI není o zjednodušování ale o standarizaci. Stejně jako docker. Tj. dřív developeři říkali "ale mě to na lokále funguje" ... Ono fungovalo, protože onen developer měl jiný webserver, jinou verzi PHP, jinou verzi ruby nebo třeba rustu. Nebo prostě pouštěl testy jinak.
Dnes má CI vždy stejné výsledky (protože jak se má co dělat máte napsané v souboru), člověk může jít do historie, vidí kdo si pouštěl jaké testy, co dělal a co rozbil.
Docker image je vždy stejný, tj. když to běží developrovi v dockeru, na CI serveru v dockeru, bude to pravděpodobně běžet i na PRODukci v dockeru ...

> Ano, 10 řádků furt opakujícího-se kódu kde se liší názvy class a proměných, které může napsat AI
Nie nemusi, ak to nemate vyriesene nejakym frameworkom (napriklad Model Driven Architecture) tak nieco robite zle. Ide to aj bez pisania kodu aj bez AI.

Ono fungovalo, protože onen developer měl jiný webserver, jinou verzi PHP, jinou verzi ruby nebo třeba rustu.

Pokud je projekt závislý na jedné verzi čehokoliv z uvedeného, tak je velmi křehký a opět to napíšu: je špatně napsaný.

Když už tady bylo zmíněné PHP, tak já jsem provozoval Gallery 2, napsanou někdy v době PHP 5.1 a provozoval jsem ji na verzi PHP 7.něco. Psali to pro PostgreSQL 7.4, já to provozoval na 12. Psali to na nějakou extra starou verzi imagemagick, a tak dále.

Dobře napsaný program nepotřebuje přesnou verzi. A proto nepotřebuje kontejner.

Tím, že se to dá do kontejneru, se jen zabetonuje tento špatný stav a sníží se tlak na zlepšení.

Na stranu druhou, občas nemusí být úplně jasné, která část jazyka se stane během pár verzí deprecated. Rust tohle řeší celkem elegantně přes edice jazyka, ale pokud vím, u PHP pár backwards incompatible změn bylo. To samé knihovny, až na výjimky typu curl se občas nějaká nekompatibilní změna API vyskytne.

To samé knihovny, až na výjimky typu curl se občas nějaká nekompatibilní změna API vyskytne.

Jenže tomuhle kontejnery také jen ublíží. Pokud se vývojář knihovny drží pevně pravidla nikdy nic nerozbít, tak potom můžu klidně vzít 10 let starou verzi, bude pomalejší, možná tam bude pár bezpečnostních chyb, ale ta moje appka bude stále fungovat.

Pokud se vývojář knihovny spolehne na to, že vše je v kontejnerech a všude se tahá přesná verze knihovny, tak o to častěji ji bude rozbíjet a o to méně bude přemýšlet nad stabilitou api do budoucna.

Holt je dobrý a špatný způsob jak použít kontejner :/ Momentálně, pro aplikace které píšu, je kontejner minimalistický, netahá s sebou celý OS, vlastně žádné zbytečné závislosti, a je pravidelně updatovaný. Hlavní přínosy pro mě nejsou stabilita prostředí, ale reprodukovatelnost buildu (což je pravda spíš zásluha Nixu), sandboxing a možnost běhu v k8s.

Situace kdy někdo vyrobí kontejner z aktuálního debianu a pak se na to vybodne mě děsí taky.

Holt je dobrý a špatný způsob jak použít kontejner

Jasně. Já jsem nad tím taky přemýšlel, když se mi moc nelíbila distribuce modulů v pythonu. Tak jsem přešel na golang. Jedna binárka, vlastně je to takový vlastní kontejner. Potřebuje to jen kernel. :-D

To samé Rust, jen mi do toho občas hodí vidle nějaká knihovna která je jen binding do C :) Nejčastěji OpenSSL, ale rustls je naštěstí už skoro všude.

> Pokud je projekt závislý na jedné verzi čehokoliv z uvedeného, tak je velmi křehký a opět to napíšu: je špatně napsaný.

Každý projekt je závislý na verzi. Nebo máte projekty které fungují v rámci major verzí knihoven a jazyků?

Resp. takhle: pokud vyvíjíte opensource, pravděpodobně ano. Pokud vyvíjíte close-source které někdo platí, většinou garantujete nějaké funkční prostředí (verze knihoven, apache vs. nginx, verze jazyku). Úpravy aby to fungovalo s jiným prostředím jsou peníze. Celkem vyhozené peníze.

Samozřejmně jednou za čas je nutný uprade, nicméně takový upgrade se musí dělat s rozmyslem ...

Resp. takhle: pokud vyvíjíte opensource, pravděpodobně ano.

To není o Open nebo Closed. Z mých zkušeností je lepší vždy používat funkce, které tam jsou již 20 let a nejsou označeny jako deprecated. Tedy nebudu používat věci vyvinuté včera, protože opět ze zkušeností a z historie víme, že je nebezpečí, že se budou měnit, bude tam chyba apod.

Výhody jsou v tom, že ty věci jsou prověřené časem, lidmi, opravené, optimalizované. A v mém týmu s tím všichni umějí pracovat. Vědí, co to umí, co to neumí, kde to má silné stránky a kde to má slabé stránky.

A z toho prostě plynou i nároky na ty knihovny apod. Pokud se to mění každý měsíc, tak to jde na blacklist. Prostě to nepoužiju. Pokud od deprecated po zrušení uběhne týden, tak to také nepoužiju. V hromadě projektů tohle víte třeba 5 let dopředu, potom ta fce zmizí z dokumentace, ale máte ještě další 2 roky na to se jí u sebe zbavit.

Takže nakonec vznikne projekt, který není problém nainstalovat, protože jako závislosti má pouze věci notoricky známé, stabilní apod. A vůbec to nezávisí na nějaké konkrétní verzi.

Což je ve výsledku nejlevnější, nejstabilnější, nedělá to problém s instalací apod.

A opravdu mě nenapadá jediná věc, která by závisela na apache vs nginx. A ještě konkrétní verze. Chtěl bych to opravdu slyšet.

A opravdu mě nenapadá jediná věc, která by závisela na apache vs nginx. A ještě konkrétní verze. Chtěl bych to opravdu slyšet.

- Projekty které používají lua-nginx
- Kód spoléhající-se na specifické funkce nginxu kvůli rychlosti (upload souborů etc.).
- Každý projekt který má víc jak jednu location poměrně dost závisí na nginxu... což samozřejmně jde přepsat i do apache, ale proboha proč?

Ona i u toho closed source je "it depends".
Většina dodavaletů bude trvat na přesné verzi systému. Na stranu druhou, když s nimi nejste vyloženě na nože, tak Vám většina řekne něco jako "tuhle knihovnu vyžadujeme 1.9.97, ale bude fungovat patrně cokoli až do 1.11.xxx včetně, jen po nás nechtěj support". A pak je na Vás, jak si to přeberete. Pokud tam máte čtyři devítky, tak holt zůstanete na 1.9.97, ale pokud jde o blogíšek paní uklízečky, tak si klidně lajsnete to zvednout na 1.11.

Když jsme potřebovali naposledy řešit btree v PHP, nic na to neexistovalo ...

No a proč jste si to nenapsali sami?

Jako mě všechny tyhle argumenty přijdou jak od člověka, kterého to nebaví. Že vás vlastně nebaví programovat, tak chcete, aby to napsal nějaký nástroj. Před x lety tady byly články s názvem "pokud se přihlašujete na server přes ssh, děláte to blbě" a byl to článek o ansible.

Jo, prostě všechny tyhle nástroje jakoby říkají "vůbec se toho počítače nedotýkej". Ale tak potom proč ten člověk jde do IT? Já jsem v IT, protože mě baví se připojovat na ssh a psát ručně příkazy. Baví mě psát kód. Takže pokud není v php btree, tak bych si prostě vzal skripta z vejšky a napsal bych to od nuly. Protože mě to baví.

Navíc už z principu, pokud to nikde neexistuje, tak je docela malá šance, že v PHP nějaký LLM zvládne btree napsat.

Navíc už z principu, pokud to nikde neexistuje, tak je docela malá šance, že v PHP nějaký LLM zvládne btree napsat.

Já jsem neřekl že to nikdo nenapsal. Já jsem řekl že neexistovala knihovna... Určitě bych řekl že implementací btree bylo dost, jenže kdo má hledat mezi haldou projektů. Oh wait, že by AI? ;-)

Takže pokud není v php btree, tak bych si prostě vzal skripta z vejšky a napsal bych to od nuly. Protože mě to baví.

To máte hezký. My jsme to nakonec napsali. Ale popravdě nevím jestli bavilo zaměstnavatele platit za člověkohodiny když by stroj dokázal ušetřit poměrně dost nákladů (protože to je furt ten samý algoritmus napsaný ve spoustě jazyků a spoustě projektů) ;-)

Jako mě všechny tyhle argumenty přijdou jak od člověka, kterého to nebaví. Že vás vlastně nebaví programovat, tak chcete, aby to napsal nějaký nástroj.

Mě baví programovat, ale nebaví mě vynalézat kolo.

"pokud se přihlašujete na server přes ssh, děláte to blbě"
Jeden server je legrace s ssh, ale až budete spravovat tisíce mašin které musejí být reprodukovatelné a vytvořené na "lusknutí" prstu tak pochopíte k čemu takový ansible, puppet, k8s a kontejnery jsou dobré. A proč je koncept mutable serveru a ručních úprav cesta do pekel (zvláště když odejde hardware nebo nedej bože že admina přejede tramvaj) ;-)

Jeden server je legrace s ssh, ale až budete spravovat tisíce mašin které musejí být reprodukovatelné a vytvořené na "lusknutí" prstu tak pochopíte k čemu takový ansible, puppet, k8s a kontejnery jsou dobré. A proč je koncept mutable serveru a ručních úprav cesta do pekel

Já vím k čemu to je. A proto že to vím, tak to odmítám. A už jsem několikrát vysvětloval proč.

Viděl jsem ansible playbooky, kde se nastavoval každý soubor v /etc/ jen tak pro srandu. Viděl jsem plabooky pro instalace čehosi, co vyžadovalo stovky kroků. A právě proto to kritizuju. Pokud něco vyžaduje stovky kroků na instalaci, tak vůbec není správné řešení na to nasadit ansible. Řešení je to opravit tak, aby se to nainstalovalo jedním apt install. Jo, já neodmítám tyhle nástroje jako takové, já odmítám to, že se používají na zakrytí toho bordelu, ve kterém ten projekt je. A tohle se vždy velmi silně nevyplatí. Prostě pokud se projekt dostane do stavu, kdy někdo jen pomyslí na to, že manuální instalace už je prostě nemožná, tak nasadíme ansible, tak by se měl především zamyslet nad tím, jak se ten projekt do tohoto stavu dostal.

až budete spravovat tisíce mašin

Spravoval jsem ručně stovky mašin. Překvapivě to šlo no problémo. A celkem jsem se nudil.

nebo nedej bože že admina přejede tramvaj

Tak je to velmi špatně zorganizováno. V každém normálním týmu je několik zastupujících se lidí. Všichni vědí to samé, všichni jsou nahraditelní. Takže pokud admina 1 přejede tramvaj, tak admin 2 přiťukne minerálkou na jeho počest a vše jede bez problémů dál.

> Řešení je to opravit tak, aby se to nainstalovalo jedním apt install

Ono by to vlastně do nějaké míry* šlo, jen potom vlastně používáme dpkg a nějaké skripty místo Ansible. Tedy nejde o filozoficky úplně jiný přístup, jen vlastně o jiný nástroj. Z praktického hlediska je potom otázka, který nástroj je lépe použitelný.

Z velké části (aspoň pro věci spustitelné přímo na cílovém serveru) by vlastně Ansible mohlo vygenerovat deb/rpm balíček, který by se nainstaloval na server. A pak by byla jen otázka, jak to pohodlně distribuovat a instalovat na několika serverech.

*) Otázka je, jak se postavit k věcem, kde třeba jeden secret sdílí více strojů

Tedy nejde o filozoficky úplně jiný přístup, jen vlastně o jiný nástroj.

Myslím, že jsme mimo. Mě jde o to, aby se nástroje typu ansible nepoužívaly na zakrytí nepořádku. Že na těch 100 instalačních kroků není vidět. A protože na ně není vidět, tak je menší tlak na jejich opravení/odstra­nění.

Pokud někdo (já), ansible používá k tomu, že tam má dva tasky, kde jeden udělá apt install a druhý udělá nastavení nastavení připojení do db v configu, tak je to správné použití tohoto nástroje.

A v tom debu je pouze binárka toho projektu, systemd unita a default config. Žádné skripty. K čemu by tam měli být skripty?

Pokud někdo potřebuje distribuovat klíče na 1000 strojů, tak samozřejmě může použít ansible nebo cokoliv. Proti tomuto jsem nikdy nic neměl.

Jo, prostě moje projekty vypadají tak, že je jedna binárka, jedna systemd unita a když je to vyloženě nutné, tak jeden config. Tečka. Deb nemá vůbec žádné skripty. A jediné, co je u některých projektů nutné nastavit, tak je to constring do db. Ale to taky není potřeba. Protože do pg se dá přihlašovat a připojovat přes unix socket.

Tedy, pokud to postavím správně, tak mi ve skutečnosti stačí "nainstalovat" dva soubory. Binárku a unitu. Deb balíček má závislost na postgresql-server. A v tom pg stačí založit správného systémového uživatele. Takže celá instalace má dva příkazy. apt install a create user. Toť vše.

Tím současně odpovídám i na poptávku Kate. O reprodukovatel­nosti. Za mě nainstalujte debian minimal, udělejte jedno apt install, nastavte connstring. Hotovo, je to nainstalované a funguje to. Pokud to potřebujete na 1000 serverů tak tyto dva kroky dejte do ansible.