C static shared library with C standard library musl (diskuse)

[BFU]

O co tady vlastne jde -- o to udelat dynamickou knihovnu (so, shared object) nebo staticky slinkovanou binarku ve ktere je nalinkovane vsechno vcetne libc ?

[rastos]

O toto.

[BFU]

Nestacilo by ten program proste zkompilovat proti nejstarsi verzi glibc na ktere se to bude pouzivat a pak spolehat na to, ze nove verze glibc jsou ABI kompatibilni se starsima (jsou) ?

Navic teda Drepper vysvetluje proc je staticke linkovani opravdu spatny napad tady:

https://www.akkadia.org/drepper/no_static_linking.html

[z_sk]

Nestacilo by ten program proste zkompilovat proti nejstarsi verzi glibc na ktere se to bude pouzivat a pak spolehat na to, ze nove verze glibc jsou ABI kompatibilni se starsima (jsou) ? 

Nie. Proste, ak mi ide o garanciu, tak sa na to spoliehať nebudem. Proste poriešim to buď statickým prekladom, alebo s programom bude nosiť aj všetky knižnice, ktoré potrebuje. Tak ako to je vo svete MS Windows. Ak chcem mat istotu.

[BFU]

I kdyz si budete tahat s sebou cely userspace, tak to stejne neznamena, ze ten userspace je kompatibilni s kernelem. Tim se cely problem posune akorat o level nize. Viz treba

https://sourceware.org/legacy-ml/libc-alpha/2016-08/msg00212.html

" * The minimum Linux kernel version that this version of the GNU C Library can be used with is 3.2, except on i[4567]86 and x86_64, where Linux kernel version 2.6.32 or later suffices (on architectures that already required kernel versions more recent than 3.2, those requirements remain unchanged). Linux 3.2 or later kernel headers are required on all architectures. "

Takze pokud vam jde skutecne o kompatibilitu az do skonani sveta, tak to snad chce nejakou virtualni masinu vcetne kernelu s nemennym emulovanym hardwarem.

Staticke linkovani tady neni reseni, navic je vhodne si precist to vysvetleni od Dreppera.

[z_sk]

O dynamickú knižnicu, ktorá ma v sebe staticky skompilovanú c knižnicu.

[rastos]

Možno sa mýlim, ale pri statickom linkovaní sa do výslednej binárky dostane zo statickej knižnice len kód, ktorý sa skutočne používa. Nie? Takže ideálne by podľa mňa nebolo prifariť celú statickú C knižnicu, ale len ten jeden symbol. Nie je mi jasné, kde sa vzal ten (t)ext funkcie stat() na stroji B a prečo sa na rovnakom mieste nemôže zobrať aj na stroji A.

Keďže sme tu v blogu a nie v poradni: nedávno som videl Torvalds on why desktop Linux sucks a pripadá mi, že môj problém je manifestáciou jeho vysvetlenia: došlo k zmene ABI v libc a preto moja binárka nezafunguje na inom distre (či dokonca inej verzii mojho distra). A skúmam, či by sa to v mojom konkrétnom prípade nedalo nejako obicyklovať.

[kralyk z abclinuxu]

Keďže sme tu v blogu a nie v poradni: nedávno som videl Torvalds on why desktop Linux sucks a pripadá mi, že môj problém je manifestáciou jeho vysvetlenia: došlo k zmene ABI v libc a preto moja binárka nezafunguje na inom distre (či dokonca inej verzii mojho distra). A skúmam, či by sa to v mojom konkrétnom prípade nedalo nejako obicyklovať.

To je velmi pěkný a velmi trefný talk. Díky za nasdílení. Ano, to je přesně ten problém.

Akorát bohužel za těch ~6 let se toho mnoho nezměnilo, Valve linux desktop nezachránil a balíčkoví a shared-library fanatici stále tvrdošíjně trvají na svém Změna je, že dnes existují / jsou rozšířenější řešení typu Flatpak nebo Snap, ale abych pravdu řekl, nejsem z toho nadšený a bez nějaké oficiálnější podpory ze strany dister to asi nikdy nebude ono...

[j]

Nikoli. V normalnim distru muzu mit knihoven kolik chci jakych verzi chci, a normalni aplikace si rekne, jaky verze jakych knihoven potrebuje.

Na widlich to ostatne funguje v tomhle ohledu uplne stejne, akorat ze tam mas 40GB vsemoznych dllek tisicu verzi bydefault, i kdyz je vubec nanic nepotrebujes.

---

Dete s tim guuglem dopice!

[xkucf03]

+1

Někteří bohužel stále podléhají falešné dichotomii, že si buď přibalím konkrétní verze knihoven k programu (statické linkování případně přibalené vlastní .so) a mám věci pod kontrolou, nebo použiji knihovny z distribuce, a pak to pod kontrolou nemám. Ale to není pravda. Stačí se podívat na nějaké modernější distribuce…

Viz předchozí diskuse na téma statické linkování.

[Heron]

Otázkou je, jestli se náhodou neřeší problém na zcela špatné vrstvě. Pokud někdo v programu používá knihovnu od dvou vývojářů a jeden z nich je magor, tak by se měl asi především zamyslet, zda by nebyla vhodná jiná knihovna nebo si to napsat sám. Asi to záleží na prahu citlivosti k těmto věcem, ale vidím lidi, kteří jsou schopni trávit hodiny s tím, aby k programu přibalili jednu zcela konkrétní verzi něčeho, namísto toho, aby věnovali stejný čas a této škodlivé závislosti se zbavili (a do budoucna si ušetřili ještě hromadu problémů).

Statická kompilace nic neřeší. Jen ztíží možnosti update bezpečnostních problémů. Na místo (automatického) update knihovny bude potřeba aktualizovat všechny statické binárky, které ji používají. Pokud tedy autor vydá novou verzi toho programu.

Valve linux desktop nezachránil

Celkem by mě zajímalo, jak by se to mělo vlastně stát.

Změna je, že dnes existují / jsou rozšířenější řešení typu Flatpak nebo Snap

To je změna k horšímu.

[kralyk z abclinuxu]

Otázkou je, jestli se náhodou neřeší problém na zcela špatné vrstvě. Pokud někdo v programu používá knihovnu od dvou vývojářů a jeden z nich je magor, tak by se měl asi především zamyslet, zda by nebyla vhodná jiná knihovna nebo si to napsat sám.

Od Torvaldse tohle byla nadsázka, na linuxu je problém i s relativně obyč knihovnami. Obecně ale tohle je něco, co si musí především posoudit ten programátor.

Statická kompilace nic neřeší. Jen ztíží možnosti update bezpečnostních problémů. Na místo (automatického) update knihovny bude potřeba aktualizovat všechny statické binárky, které ji používají.

No a co, tak zaktualizuješ statické binárky. Stejně musíš u každého používaného programu, kde ti záleží na bezpečí, trackovat i ten program jako takový, nejen závislosti. U open-source programu v jazyce s jazykovým balíčkovačem projekt deklaruje svoje závislosti strojově čitelným způsobem už v upstreamu, ie. lze to u nich řešit automatizovaně, přestože jsou staticky linkované.

Další věc je, že shared linkování není vždycky technicky možné/vhodné - viz třeba header-only a/nebo těžce templated/generické knihovny v C/C++/Rustu/...

Celkem by mě zajímalo, jak by se to mělo vlastně stát.

Za mě by bylo fajn, kdyby:

• Existoval nějaký verzovaný mezi-distribuční standard 'systémového rozhraní' (tj. sada základních nejpoužívanějších knihoven a frameworků potřebných pro desktop), něco jako má Mac OS nebo Android. Ie. mohl bych říct "můj program vyžaduje Linux Deskop API 12.34" a měl bych jistotu, že přislušné knihovny budou poskytnuty v přísluěné verzi (nebo kompatibilní) na většině dister.
• Existoval nějaký registr, kde by bylo možné najít knihovnu/program/framework/whatever a zjistit si, jaký balíček to poskytuje v jakém distru a v jaké verzi. Něco takového už existuje, ale chtělo by to oficiální podporu, aby to nebyl jen random tool, který někdo někde náhodou provozuje.
• Uměly distribuční balíčkovače spolupracovat s jazykovými balíčkovači používanými upstream projekty a např. vyčíst dependence a tam kde to jde a dává smysl, poskytnout sestavovacímu nástroji distribuční sdílený knihovny, zbytek nechat nalinkovat staticky.
• ...

Prostě obecně nástroje a standardy, aby mohli programátoři cílit linuxový desktop obecně a ne jen amorfní nejasnou hromadu dister, kde nikdy nikdo pořádně neví, co kde bude nebo nebude fungovat a v jaké verzi atd., díky čemuž programátoři i maintaineři pálí zbytečně kvanta času...

[Heron]

No a co, tak zaktualizuješ statické binárky. Stejně musíš u každého používaného programu, kde ti záleží na bezpečí, trackovat i ten program jako takový, nejen závislosti.

Jasně, ale musíš čekat, než to autor překompiluje. Pokud je chyba jen v linkované knihovně, tak stačí jen updatnout jednu knihovnu. Ano, není to dlouhodobé řešení, pokud je nějaký projekt mrtvý, tak se stejně musí přejít na něco jiného. Ostatně tohle je vidět právě třeba na verzích pro Windows, kdy při zjištění nějaké bezpečností chyby mám na linuxu už týdny updatovanou tu jednu knihovnu a jsem v pohodě, tak na Windows stále čekám na novou verzi, protože program si tahá všechna dllka s sebou. Takže autor vydává novou minor verzi jen k vůli update jednoho dll.

Existoval nějaký verzovaný mezi-distribuční standard 'systémového rozhraní' (tj. sada základních nejpoužívanějších knihoven a frameworků potřebných pro desktop), něco jako má Mac OS nebo Android. Ie. mohl bych říct "můj program vyžaduje Linux Deskop API 12.34" a měl bych jistotu, že přislušné knihovny budou poskytnuty v přísluěné verzi (nebo kompatibilní) na většině dister.

No a nebo to taky vzít tak, že každé disto je samostatný OS a tak k tomu přistupovat. Nikdo nechce stejný standard pro win, mac, android, tak proč by to mělo být pro OS postaveném na kernelu linux?

Prostě obecně nástroje a standardy, aby mohli programátoři cílit linuxový desktop obecně a ne jen amorfní nejasnou hromadu dister, kde nikdy nikdo pořádně neví, co kde bude nebo nebude fungovat a v jaké verzi atd., díky čemuž programátoři i maintaineři pálí zbytečně kvanta času...

Upřímně řečeno, já jsem za nějakou potenciálovou bariéru vlastně rád. Tohle se řeší furt dokola. Zatímco spousta projektů vydává balíčky od roku 1998 (kdy jsem si poprvé vyzkoušel linux) dodnes, tak někteří s tím stále mají problém. Evidentně není problém na straně linuxu.

Je to prostě prasením těch autorů. Sám jsem dělal balíčky pro stable verze debu s vlastním python programem (není veřejný), člověk věděl, jakou verzi pythonu má očekávat, udělal si závislosti na systémových balíčcích a je to. No problémo. Ano, znamená to netahat závislosti z náhodných míst na internetu, ale to je přece účel distribuce. Stačí napsat apt install můj_úžasný_program, natahá si to python moduly a jede to.

Ne, zrovna tento týden mi někdo vysvětloval (taky milujete, když vám nějaké ucho vysvětluje, co všechno děláte blbě? Já si to pokaždé užívám.), že je nutné si všude tahat venv, pip atd. Prostě jen nepochopili, co to je distribuce a v čem spočívají její výhody. (Navíc, když už chci instalaci "the python way", tak si nastavím setuptools a potom na veškerou instalaci stačí jeden pip install a vůbec nemusím balíčkovat venv.)

A teď, když balíčkuju něco v golangu, tak i když je to jedna binárka (klidně může být i statická, targety na to mám), tak ten balíčkovací proces je zcela stejný jako pro python. Závislosti tam jsou taky, ale logicky ne na modulech.

[Martin Tůma]

Takže autor vydává novou minor verzi jen k vůli update jednoho dll.

To je ale spíš zbožné přání, než realita. Ve skutečnosti většina menších projektů nevydá ani příští regulérní verzi s tou opravenou DLL. (Ano, ani já ne, pokuď už to není CVE s vlastním webem a vlastním logem)

No a nebo to taky vzít tak, že každé disto je samostatný OS a tak k tomu přistupovat. Nikdo nechce stejný standard pro win, mac, android, tak proč by to mělo být pro OS postaveném na kernelu linux?

Protože se z toho jinak brzo zblázníš. I když ti je dneska OBS schopné ušetřit spoustu práce, furt je každý nový build značný overhead, na který zejména menší projekty už prostě nemají zdroje. Velké/známé projekty to netrápí, za ně to dělají lidé z dister, ale aby si se velkým/známým stal, potřebuješ nejdřív ten SW dostat k lidem, k čemuž zase potřebuješ ty balíčky...

[Heron]

To je ale spíš zbožné přání, než realita. Ve skutečnosti většina menších projektů nevydá ani příští regulérní verzi s tou opravenou DLL. (Ano, ani já ne, pokuď už to není CVE s vlastním webem a vlastním logem)

No právě. A teď tohle někdo chce do linuxu.

I když ti je dneska OBS schopné ušetřit spoustu práce, furt je každý nový build značný overhead, na který zejména menší projekty už prostě nemají zdroje.

Něco musí být špatně. Když nějaký software nemá balíček pro můj os, tak stáhnout zdrojáky a ono se to vždycky nějak zkompiluje. Jasně, někdy je to o hledání dev knihoven, ale ještě se nestalo, že by to nešlo. Od roku 2015 provozuju servery na FreeBSD. Team FreeBSD je o dost menší, než (velká) linuxová distra, přesto není žádný problém cokoliv zkompilovat i tam. (Ano, některé méně používané porty vykazují známky rozbitosti, ale podařilo se.) Fakt nevěřím tomu, že pro autora toho softu bude tak velký problém to rozběhat na jiném dostatečně rozumném distru (tj nebavím se o spciálních projektech s vlastními minimalizovanými c knihovnami apod).

[Martin Tůma]

Fakt nevěřím tomu, že pro autora toho softu bude tak velký problém to rozběhat na jiném dostatečně rozumném distru (tj nebavím se o spciálních projektech s vlastními minimalizovanými c knihovnami apod).

Jistě, někde to bude víc práce, někde míň, ale při dostatečné snaze to asi sestaví kdekoliv. Jenomže tahle snaha není zadarmo a ty zdroje by se daly využít na mnohem zajímavější věci...

[kralyk z abclinuxu]

Od roku 2015 provozuju servery na FreeBSD. Team FreeBSD je o dost menší, než (velká) linuxová distra, přesto není žádný problém cokoliv zkompilovat i tam.

Připomínám, že se bavíme specificky o desktopu. O tom je ten Linusův talk. Tj. zmiňovat BSD servery není moc relevantní.

Server má typicky relativně úzké konkrétní zaměření, které musí splňovat co nejlépe. Ten tradiční distribuční/balíčkový model mi tam dává mnohem větší smysl, distribuce je v podstatě takový kurátor balíčků, na které se server může spolehnout. To je ok.

Desktop oproti tomu potřebuje být výrazně flexibilnější a s co nejširším záběrem, je to něco úplně jiného. A distribuce tohle moc nedávají.

Fakt nevěřím tomu, že pro autora toho softu bude tak velký problém to rozběhat na jiném dostatečně rozumném distru

Ale jo, ono to většinou nějak jde, není to raketová věda, ale je to strašně drahé, frustrující, zbytečné. Když chceš vydávat nightly binárky pro co nejvíc linuxových dister, tak to abys ideálně měl build systém pro každý distro*, resp. každou rodinu a musíš řešit problémy víceméně u každýho zvlášť. Ber taky v úvahu, že to není jednorázová akce, ty distra se mění, software se mění, musíš si udržovat přehled, co která distribuce kde změnila a kontinuálě řešit, na kterém distru tvůj software nekompiluje zrovna dneska. Další věc je, že to, že se ti software sestaví a nainstaluje ještě nutně neznamená, že bude fungovat za běhu, takže abys to ještě ideálně na každým druhu distra testoval...

Vývojáři to nechtěj dělat, protože je to absurdní práce, spálíš na tom hromady času, ale přitom nedosáhneš žádnýho rozumnýho výsledku. Získá tou prací tvůj software nějakou zajímavou fíčuru? Opraví se tim nějaká funkční chyba? Ne, jenom prostě na nějakým distru XY se zbavíš problému jenom proto, abys následující den řešil nějakou podobnou blbost na distru QZ.

*) V tomhle naštěstí hodně pomáhá další tradicionalisty těžce hejtovaná technologie - docker. Na jeden příkaz může mít člověk userspace nějakýho jinýho distra.

[Heron]

Připomínám, že se bavíme specificky o desktopu. O tom je ten Linusův talk. Tj. zmiňovat BSD servery není moc relevantní.

No já v tom až tak velký rozdíl nevidím. Prostě místo definovaných závislostí na db klientovi bude v "desktop" balíčku definovaná závislost na gui tooltkitu. Já nějak moc nerozlišuju mezi serverem a desktopem. Stejně většinu věcí řeším na řádce.

Desktop oproti tomu potřebuje být výrazně flexibilnější a s co nejširším záběrem, je to něco úplně jiného. A distribuce tohle moc nedávají.

Nemám pocit, že by to "moc nedávaly". V repositářích najdu všechno, co potřebuju.

V tomhle naštěstí hodně pomáhá další tradicionalisty těžce hejtovaná technologie - docker

Přidávám se k těm "tradicionalistům". Resp. takto, pokud to někdo chce používat jako pomůcku při vývoji, tak klidně. Ale ať si to neplete s balíčkovacím systémem. Koneckonců už jsem k tomu taky něco napsal.

[Martin Tůma]

Nemám pocit, že by to "moc nedávaly". V repositářích najdu všechno, co potřebuju.

To by mě teda zajímalo, co máš za distribuci, protože já jsem dost velká "konzerva" a přesto několikrát do roka narazím na SW, který v Arch Linuxu, který bych si dovolil co do množství dostupného SW zařadit někam na špici pelotonu, chybí (občas i v AURu)... Běžný "konzument obsahu" už si dneska na PC možná vystačí s browserem, ale jakmile začneš dělat něco kreativnějšího, specializované tooly přijdou vhod. A pro spoustu oblastí existují velice pěkné, často velmi komplexní tooly, které nemají alternativu a přesto o ně v distribucích nezavadíš, pokuď tedy zrovna náhodou někdo "stejně postižený" jako ty pro tu distribuci nedělá baliče.

[Heron]

Debian. A nejsem tady první den, takže nehodlám vypisovat vše, co používám. Ostatně, něco už i v této diskusi zaznělo (blender zejména jako VSE pro střih videa, k tomu na řádce ffmpeg), dále tady zazněl golang, python, takže obraz si udělej sám.

[Martin Tůma]

Debian? Jako známý bonmot pravil, že: "co není v Debianu, neexistuje, co není ve Slackware není potřeba" ale to se psal rok 2000... Dneska v Debianu nejsou balíčky, který jsou ve všech moderních distribucích roky a to se ani nemusím bavit o mé "oblíbené" GIS sekci. Pokuď je v Debianu (alespoň v geologicky aktuální verzi) všechno co potřebuješ tak máš dle mých zkušeností buď neuvěřitelné štěstí, nebo žiješ strašně nudný "IT život".

[kralyk z abclinuxu]

TL;DR "Mně to nevadí, takže to není problém."

Přidávám se k těm "tradicionalistům". Resp. takto, pokud to někdo chce používat jako pomůcku při vývoji, tak klidně. Ale ať si to neplete s balíčkovacím systémem. Koneckonců už jsem k tomu taky něco napsal.

Balíčkovací systém to skutečně není, to máš zcela pravdu. Ta věc umožňuje strojově popsat, jak se konfiguruje běhový prostředí pro tu aplikaci, to prosředí zabalit a hotový spustit na víceméně jakýmkoli systému bez nutnosti změny konfigurace toho systému, což balíčkovací systém neumí.

Ruční výroba je hezká věc a v rámci hobby se tomu taky občas věnuju, když to ale po mě bude někdo chtít v práci, musí počítat s tim, že to je pomalý a chybový proces.

[Heron]

Ta věc umožňuje strojově popsat, jak se konfiguruje běhový prostředí pro tu aplikaci, to prosředí zabalit a hotový spustit na víceméně jakýmkoli systému bez nutnosti změny konfigurace toho systému, což balíčkovací systém neumí.

Ano a přesně tohle umožňuje prasit. Zatímco kdyby se vývojář držel jen toho, co mu nabízí distro, tak by napsal robustní program, který používá jen dostatečně rozšířené závislosti. Tím, že se to zabalí do kontejneru, tak si někteří ani nevšimnou, že ten program má 500 externích závislostí z náhodných míst na internetu (a tedy dost velké riziko).

Ruční výroba je hezká věc a v rámci hobby se tomu taky občas věnuju, když to ale po mě bude někdo chtít v práci, musí počítat s tim, že to je pomalý a chybový proces.

Jaká ruční výroba? Nevím, na to co má být narážka, ale na make package není nic ručního. Resp je to přesně tak ruční, jako si ručně napsat dockerfile.

Jako já proti dockeru nic nemám (i když si myslím, že se dá perfektně obejít bez něj a že řeší problém, který by ani neměl vzniknout) a jsou lidi, kteří si veškeré závislé image vyrábí sami. Ale i oni jsou schopní argumentovat tím, že balíček vyrábět nebudou, protože už mají docker. A přesně jako reakci na ty jsem napsal ten článek.

[kralyk z abclinuxu]

Ano a přesně tohle umožňuje prasit. Zatímco kdyby se vývojář držel jen toho, co mu nabízí distro

Když se bude vývojář držet jen toho, co mu nabízí distro, tak jeho software bude (obecně vzato) fungovat jenom na tom jednom kokrétním distru, případně dokonce jenom na jedné verzi. Tj. tohle nic neřeší.

Jaká ruční výroba? Nevím, na to co má být narážka, ale na make package není nic ručního.

Bylo to narážka na prosazování ručních konfigurací po SSH. Na make package je ruční to, že musim vyřešit dependence mého SW pro konkrétní distra nebo i verzi. Pokud vim, tohle nejde aktuálně dělat automatizovaně a je to jeden z bodů ke zlepšení, který jsem zmiňoval v tom komentu výše.

[Heron]

Když se bude vývojář držet jen toho, co mu nabízí distro, tak jeho software bude (obecně vzato) fungovat jenom na tom jednom kokrétním distru, případně dokonce jenom na jedné verzi.

Ne, nebude. Myslel jsem to tak, že když bude používat pouze knihovny, které jsou v pěti nejrozšířenějších distrech a které budou ještě navíc stejné, tak nebude mít problém.

Bylo to narážka na prosazování ručních konfigurací po SSH.

O žádné prosazování se nejedná, ale uznávám, že to chce trochu víc kontextu a pokud nejsi admin, tak to může unikat. Pointa je, že někteří prosazují ansible (a spol) i pro začátečníky, kteří vůbec neví nic o tom, co vlastně spravují a svět vidí jen přes ty nástroje. Osobně si myslím, že dobrý admin si prostě musí na stroj sáhnout (stejně jako sushi master 8 let jen proplachuje rýži, aby získal cit). Až bude umět adminovat stroj "levou zadní", teprve potom si může "ulehčit" práci automatizací.

A je to důležité i z hlediska toho, aby poznali, který nástroj je dobrý a který ne. Když jsem zjistil (kdysi), že v ansible není modul pro btrfs, tak jsem hledal existující moduly na githubu (což mimochodem bylo i doporučení přímo od ansible propagátorů) a ty výtvory fakt stály za to. Ti lidi evidentně nic nevěděli o btrfs, podle nějaké šablony vytvořili ansible modul a tam dost naivně volali btrfs na shellu. Ideální nástroj pro ztrátu dat. Stejně tak se pokaždé dívám na strukturu databáze a i to je hint, jestli s daným software dál ztrácet čas. Je toho víc. Ale pokud je to pro někoho jen neproniknutelná fasáda, tak si vybere špatně.

Navíc ti možná uniká i pointa toho článku. Nevím jak kdo, ale já tuhle práci dělám i proto, že mě fakt baví všechny ty technické výpisy, psaní příkazů apod.. Nedělám to jen proto, aby bylo něco zprovozněno, něco nového vytvořeno, ale já se fakt rád dívám dlouhé výstupy z různých příkazů. Stejně jako truhláři voní dřevo. Proto je dost podivné, pokud někdo doporučuje se nedotýkat toho, s čím pracuje.

[Martin Tůma]

Myslel jsem to tak, že když bude používat pouze knihovny, které jsou v pěti nejrozšířenějších distrech a které budou ještě navíc stejné, tak nebude mít problém.

Problém možná ne, ale spoustu práce ano. I pouhé RPM se zcela triviálníma závislostma na nejrozšířenejším GUI frameworku si žádá hodiny práce a testování, protože na každé distribuci jsou ty balíčky jinak rozdělené a pojmenované... A to máme jenom RPM, dtto pro DEB a to stále ještě nemáme nic mimo úplný mainstream (Gentoo, NixOS, *BSD, ...) kde ani OBS nepomůže.

[trekker.dk]

Ne, nebude. Myslel jsem to tak, že když bude používat pouze knihovny, které jsou v pěti nejrozšířenějších distrech a které budou ještě navíc stejné, tak nebude mít problém.

Jenže tohle vývojářům, co ve svojí aplikaci naprosto nutně potřebují použít libobscure verze 0.0.1-dev-actually-scratchpad-finished-9hours-ago, nevysvětlíte.

O tom, jak strašně časově náročné musí být řešit program v distribuci, která dva roky zajišťuje stejné verze knihoven, ani nemluvě.

[kralyk z abclinuxu]

Jenže tohle vývojářům, co ve svojí aplikaci naprosto nutně potřebují použít libobscure verze 0.0.1-dev-actually-scratchpad-finished-9hours-ago, nevysvětlíte.

Haha, kéžby. Můj 'oblíbený' příklad (kterej jsem tu už asi psal - sorry, pokud to čtete podruhý) je Boost, kde se rozhodli přejmenovat nějakou funkci/třídu. Sice tam tu starou nechali jako alias, označený jako deprecated k pozdějšímu odstranění, ale bohužel to deprecated okno nebylo dostatečně dlouhý, takže po odstranění (při kterém nebyla bumpnuta major verze) nastala situace, kdy LTS distra ještě neměly tu novou a up-to-date distra už neměly starou. Samozřejmě můžeš to odbýt s tim, že autoři Boostu jsou debilové, ale to mi ve chvíli, kdy to musim řešit, vůbec nijak nepomůže. To bych si taky mohl říct, že debilové jsou úplně všichni a psát si sám úplně všechno jen proti libc nebo rovnou kernelu.

Cílit software na linuxový distra je asi jako když seš lučištník, máš za úkol trefit 10 terčů pohybujících se všemi směry a máš k dispozici 3 šípy. (Pokud to není zjevné, ty šípy představují buď budget, pokud to děláš komerčně, nebo volný čas a morál řešit kraviny, pokud to děláš jako hobby.)

[deda.jabko]

Samozřejmě můžeš to odbýt s tim, že autoři Boostu jsou debilové, ale to mi ve chvíli, kdy to musim řešit, vůbec nijak nepomůže. To bych si taky mohl říct, že debilové jsou úplně všichni a psát si sám úplně všechno jen proti libc nebo rovnou kernelu.

Ja uz se do teto faze de facto dostal. Obvykle to probiha ve trech krocich.

1. Zacnu neco s tim, ze to bude jednoduche, protoze na to pouziju tu a tu knihovnu, na tamto onu a jenom to nejak slepim, bude to brnkacka.

2. Ze zacatku tu funguje hezky, ale kdyz chci neco trochu slozitejsiho, zvrhne se to v opravu lakatose a zjistim, ze knihovna ma nejaky fundmantalni bug, ktery nejde jednoduse opravit.

3. Napisu si tu funkcionalitu sam a zjistim, ze to nebylo tak narocne, jak jsem si puvodne myslel.

[podlesh]

2. Ze zacatku tu funguje hezky, ale kdyz chci neco trochu slozitejsiho, zvrhne se to v opravu lakatose a zjistim, ze knihovna ma nejaky fundmantalni bug, ktery nejde jednoduse opravit.

3. Napisu si tu funkcionalitu sam a zjistim, ze to nebylo tak narocne, jak jsem si puvodne myslel.

Ono je to výrazně lehčí když se člověk může poučit z již existující implementace.

[petr_p]

Mám pocit, že problém má dvě strany: autora a uživatele. Autor softwaru chce dělat jen jednu binárku (balík, image), protože to je méně práce, než řešit každou distribuci zvlášť. Uživatel naopak chce software pro svoji distribuci, protože jeho distribuce je ta nejlepší, a nechce být zatěžován problémy jiných distribucí.

Z toho by se mohlo zdát, že řešení, které uspokojí obě strany, je vydávat statickou binárku. Jenže binárka není všechno. Takový program nekomunikuje jen s jádrem (na jedné konkrétní architektuře), ale potřebuje konfigurační soubory (kde je DNS server?), fonty (jak vypadá váš program v thajském národním prostředí?), grafický výstup (X11 nebo Wayland?)

Takže binárku se všemi ostatními soubory (a toolkitem, který umí X11 i Wayland) zabalíme do archivu a budeme tomu říkat Docker image. Jenže takový image má vyšší stovky megabajtů. Bude uživatel s každou aktualizací pro každou aplikaci chtít stahovat a instalovat stovku megabajtů? Nebude. Autor si problém vyřešil, ale udělal problém uživateli. A že těch aktualizací bude, protože ve stovkách megabajtů je tolik chyb, že poctivý autor bude vydávat každý druhý den.

Naivní autor Docker image rozdělí na dva: základní (distribuční) a aplikační vrstvu a prohlásí, že aplikační závisí na základní. Jenže tím se problém vůbec nevyřešil, protože co není v jedné vrstvě, musí být ve druhé. A hlavně ta závislost je statická, takže když uživatel bude mít deset aplikací, tak bude potřebovat deset různých základních vrstev.

Proto přichází technologie jako AppImage nebo Snap, které ruší mantru statického linkování a verzování a vrací se k vrstvám s dynamickými závislostmi. Takže uživatel nemá deset verzí základních vrstev, ale ideálně jen jednu. To samozřejmě vyžaduje definici stabilního API a udržování kompatibility.

A protože vše, co mohlo být vynalezeno, již vynalezeno bylo, stačí se podívat na Linusem obdivované Windows a člověk hned pochopí, proč standardní instalace Windows sežere několik (desítek?) gigabajtů: protože akumuluje všechna historická API, aby aplikační vrstva (tj. MSI archiv s instalátorem aplikace) mohl být (relativně) malý. Tato podoba může mít historické důvody (aplikace se musela vejít na disketu), ale také právní (autoři aplikací nemají právo distribuovat částo proprietárních Windows). Nakonec komerčně úspěšné distribuce jako třeba RHEL nedělají nic jiného, než že skrze obsažený software definují ABI, které pak podporují deset let, a jejich uživatelé pak logicky žijí v zajetí myšlenky, že všechny aplikační závislosti musí být v RHELu. A pokud Linus vychvaluje ABI Linuxu, tak to dělá přesně ze stejného důvodu. Podívejte se na stále rostoucí velikost jádra. Tajemství Linuxu je, že neodstraňuje rozhraní a je tudíž příliš velký na to, aby někdo seriózně udržoval jeho fork.

Čili problém jednotné distribuce linuxových aplikací, ač se jeví technický (fragmentace API a ABI do myriád distribucí), je veskrze ekonomicko-právní (je „levné“ a legální založit si vlastní distribuci). Pokud Linus ve videu se ptal publika, jestli všichni spravují distribuční balíky a jestli si nemyslí, že by mohli dělat něco užitečnějšího, tak je ve skutečnosti vyzýval, aby všichni přešli na jednu distribuci.

(Poznámka k „užitečnosti distribucí“: Ani Docker, ani AppImage by neexistovaly bez práce balíčkářů – všechny zdrojové recepty bundlovacích formátů začínají instalací distribučních balíčků. Jinak řečeno distribuční balíky jsou a budou potřeba. Jen nepanuje shoda, kolik potřebujeme distribucí.)

[trekker.dk]

Bude uživatel s každou aktualizací pro každou aplikaci chtít stahovat a instalovat stovku megabajtů? Nebude. Autor si problém vyřešil, ale udělal problém uživateli. A že těch aktualizací bude, protože ve stovkách megabajtů je tolik chyb, že poctivý autor bude vydávat každý druhý den.

No, je otázka, jestli je dneska problém stahovat stovky megabajtů - na to jsou lidi zvyklí. Krom toho je to spíš akademická otázka, "poctivých autorů", kteří se o ten balík starají tak pečlivě, aby vydávali aktualizace kvůli chybám v knihovnách, bude ke spočítání na prstech jedné ruky.

A pokud Linus vychvaluje ABI Linuxu, tak to dělá přesně ze stejného důvodu. Podívejte se na stále rostoucí velikost jádra.

Schválně, jestli se ABI a zpětná kompatibilita na rostoucí velikosti jádra bude podílet aspoň z 5%. Já bych si tipnul, že v tomhle jste mimo a tolik to nebude ani náhodou.

[petr_p]

"poctivých autorů", kteří se o ten balík starají tak pečlivě, aby vydávali aktualizace kvůli chybám v knihovnách, bude ke spočítání na prstech jedné ruky.

Takhle bezpečný software chceme? Opravdu chceme více nemocnic v Benešově, produktovodů Colonial Pipeline a Národních knihoven? Připomínám, že uživatel již nyní může srovnávat s tradičními distribucemi, které tímto problém netrpí.

Schválně, jestli se ABI a zpětná kompatibilita na rostoucí velikosti jádra bude podílet aspoň z 5%.

Já si kompiluji jádro sám, takže od první instalace mám konfigurační volby stejné. Historická data nemám, protože držím jen poslední tři jádra, ale že velikost roste, pozoruji. Byly doby, kdy se vešlo na disketu. A jestli narážíte na nové a nové ovladače, tak si uvědomte, že odstraněný ovladač je pro uživatele stejný problém, jako rozbité ABI.

[Martin Tůma]

Takhle bezpečný software chceme? Opravdu chceme více nemocnic v Benešově, produktovodů Colonial Pipeline a Národních knihoven?

Ano, přesně takhle to uživatelé chtějí. Kdyby to chtěli jinak, tak by ty náklady spojené s tím dělat to pořádně (TM) museli zaplatit buď v penězích, nebo v chybějících featurách toho SW. Ale trh říká, že to nechtějí.

[trekker.dk]

Já si kompiluji jádro sám, takže od první instalace mám konfigurační volby stejné.

Tak to si zkuste udělat diff těch configů, schválně, jak "stejné" ty konfigurační volby budou.

Byly doby, kdy se vešlo na disketu.

To ale neznamená, že za ten nárůst velikosti může ABI a zpětná kompatibilita.

[petr_p]

Konfiguráky jsou stejné, jak jen to možné. Nové volby, na které se ptá "make oldconfig", obvykle vypínám.

Samozřejmě, že za nárůst nemůže jen zpětná kompatibilita. (Občas někdo udělá kus kódu se stejným rozhraním složitější a tedy i větší.) Podle mě z velké části je to nevypnutelná nová funkcionalita. (Nikdo se neobtěžoval udělat ji volitelnou. Nebo je tam kvůli ovladačům, které ale mám vypnuté.)

[kralyk z abclinuxu]

Jasně, ale musíš čekat, než to autor překompiluje.

U open source projektu ne, ne?

No a nebo to taky vzít tak, že každé disto je samostatný OS a tak k tomu přistupovat.

No jo, jenže to vede k tomu, že místo 2% market share máš 20 × 0.1% a ultimátně málo softwaru. A samozřejmě tím pádem se budou prosazovat řešení typu Flatpak.

Je to prostě prasením těch autorů.

Tohle je IMO laciná zkratka. Ano, autoři do nějaký míry prasí, ale je to do do nějaký míry spolu-způsobený tou roztříštěností, protože prostě dělat to správně je strašnej o*er...

Sám jsem dělal balíčky pro stable verze debu s vlastním python programem (není veřejný), člověk věděl, jakou verzi pythonu má očekávat, udělal si závislosti na systémových balíčcích a je to. No problémo.

To je jeden z nejjednodušších možných scénářů, takže se nedivim, že bez problému. Oproti tomu snažit se dostat třeba nějakou složitější kompilovanou GUI aplikaci (co třeba nedejbože interaguje s hardwarem) na pokudmožno co nejvíc dister je utrpení.

Ne, zrovna tento týden mi někdo vysvětloval (taky milujete, když vám nějaké ucho vysvětluje, co všechno děláte blbě? Já si to pokaždé užívám.), že je nutné si všude tahat venv, pip atd. Prostě jen nepochopil, co to je distribuce a v čem spočívají její výhody.

Já tomu rozumim. Stává se mi, že chci použít třeba nějaký python prográmek dočasně nebo pro nějakej specifickej účel a moc nevidim důvod si do systému instalovat X nějakejch dependencí jenom proto, abych je po nějaký době zase páral ven. S tim venv apod. to funguje automatizovaně "z krabice", nepotřebuješ sudo a na konci prostě jen smázneš adresář.

[Heron]

U open source projektu ne, ne?

Jo, tam ne.

No jo, jenže to vede k tomu, že místo 2% market share máš 20 × 0.1% a ultimátně málo softwaru. A samozřejmě tím pádem se budou prosazovat řešení typu Flatpak.

Tomuhle nějak nerozumím. Že bych měl v distru málo software nějak nepocituju. A na market share nehraju.

To je jeden z nejjednodušších možných scénářů, takže se nedivím, že bez problému.

To spíš byla ilustrace, jak by se IMO mělo postupovat. To, že si svůj program někdo slinkuje s obskurní knihovnou a potom si stěžuje jaksi není problém té distribuce. A k tomu nejjednoduššímu, no troufnu si říct, že takových 90% balíčků (na serveru 100%) je právě tohoto typu. cli utilitky nebo služby. Jednoduchej balíček, soubory, vytvořit usery a případně spustit službu.

Oproti tomu snažit se dostat třeba nějakou složitější kompilovanou GUI aplikaci (co třeba nedejbože interaguje s hardwarem) na pokudmožno co nejvíc dister je utrpení.

Když jsem psal o tom balíčku od roku 1998, tak jsem měl na mysli konkrétně gimp. Dneska mám blender, v mnoha obhledech nejlepší 3D modelovací software na světě. Někde mezi tím jsem hrál nativně 3D hry (zejména od Id).

Stává se mi, že chci použít třeba nějaký python prográmek dočasně nebo pro nějakej specifickej účel a moc nevidim důvod si do systému instalovat X nějakejch dependencí jenom proto, abych je po nějaký době zase páral ven. S tim venv apod. to funguje automatizovaně "z krabice", nepotřebuješ sudo a na konci prostě jen smázneš adresář.

No tak na vyzkoušení pro osobní potřebu klidně, ale ne pro distribuci produkčního software.

[Martin Tůma]

Když jsem psal o tom balíčku od roku 1998, tak jsem měl na mysli konkrétně gimp.

A aby to byli schopní vůbec zabalíčkovat, tak si museli napsat vlastní obskurní GUI toolkit... Kde dnes mohl linux být, kdyby gimp ty balíčky od roku 98 neměl!

[Heron]

museli napsat vlastní obskurní GUI toolkit

Který se používá dodnes a tvoří jeden ze dvou hlavních standardů, které se používají pro FOSS grafické programy na různých platformách.

Fakt té kritice nějak nerozumím. Balíčky jsou špatně, grafické tookity jsou špatně. Takže co teda?

[Martin Tůma]

Který se používá dodnes a tvoří jeden ze dvou hlavních standardů, které se používají pro FOSS grafické programy na různých platformách.

No právě... Svět by byl o tolik lepší místo, kdyby tu GTK nebylo (předpokládám tedy, že by se hegemonem stalo Qt a ne Athena)

[Martin Tůma]

Balíčky jsou špatně

Balíčky jsou správně (TM). A já jsem ten poslední, kterej by tady obhajoval nějakej Flatpack, ale taky vidim, nebo ještě přesněji žiju v realitě, kde každý den vidím, jaký obrovský náklady to přináší, dělat to správně (TM).

[j]

U OS taky ...

Jednoduse proto, ze ta vec se s 99,9% pravdepodobnosti neprekompiluje vuci knihovnam ktery mas, protoze autor je prase. Takze by sis nejdriv musel vytvorit kompletni prostredi vcetne vsech spravnych verzi naprosto vseho, coz velmi casto ani nemas jak, protoze nikde nezjistis, jaka verze je ta spravna a autor to distribuuje v podobe binarniho blobu.

---

Dete s tim guuglem dopice!

[xkucf03]

Přijde mi, že ses zase upnul na nějaký technický detail, který není tak úplně podstatný a nelze jím vysvětlit ten problém. Ty příčiny jsou dlouhodobě někde jinde:

• Při koupi počítače uživatel dostane MS Windows, aniž by se ho na to v drtivé většině případů někdo ptal – prostě je nucen zaplatit licenci/výpalné Microsoftu v ceně počítače. Vracení nechtěných licencí je problém, byť se to občas někomu povede.
• Stát podporuje proprietární software včetně těch MS Windows např. skrze školy nebo úřady.
• Stále existuje hardware, pro který nejsou svobodné ovladače. Tady se situace obrovsky zlepšila a dá se říct, že už je to skoro dobré, ale pořád to jistou překážku pro běžné uživatele představuje.
• Stále existuje řada softwaru, který běží jen na MS Windows a nejde (spolehlivě a pohodlně) provozovat ani pod Wine. Tohle je dneska větší problém než ten HW, byť se to taky hodně zlepšilo, protože spousta aplikací se přesunula na web (což je sice taky problém, ale z jiných důvodů… nicméně z tohoto úhlu pohledu je to dobře a hraje to do karet GNU/Linuxu).
• Všemožné drobné problémy: např. ti zamrzne počítač (třeba jen GUI, ale pro BFU je to konečná) v důsledku jedné problémové aplikace (typicky WWW prohlížeč) nebo ti nějaké I/O přenosy běžící na pozadí přetíží systém tak, že je dočasně nepoužitelný pro interaktivní práci, nebo při připojování USB flashky klikneš na „otevřít ve správci souborů“ a ono je to napsané tak blbě, že to běží asynchronně a správce se otevře dřív, než se disk připojí, takže to skončí chybou, nebo ti přestane fungovat tak základní věc, jako je schránka, nebo nejde tisknout v měřítku… obecně mizerné QA, ledabylý neřízený vývoj, mizerné testování, špatně navržené a řízené procesy.
• Nesoustředění se na vývoj kvalitního softwaru a upřednostňování nesouvisejících politických a sociálních témat.
• Neustálé přepisování všeho, dementní UI, hnusná grafika, v nové verzi ti zmizí používané funkce, občas si vzpomeneš na něco, co před deseti nebo dvaceti lety fungovalo a dnes nefunguje nebo chybí atd.

Oproti těmto problémům je nějaký spor, zda linkovat staticky nebo dynamicky, zcela irelevantní. Ty výše zmíněné problémy mají na výsledek řádově větší dopad.

Ale hlavně: na GNU/Linuxu ti nikdo nebrání linkovat staticky – já ti sice do diskuse napíšu, že je to fuj, ale to ti v úspěchu nijak nebrání. Klidně si můžeš distribuovat svůj software jako Flatpak, Snap, nebo prostě tar.gz či ZIP archiv, který se rozbalí a následně se spustí skript/binárka, nebo mít jednoduchý instalátor nebo dát na web návod ve stylu curl https://kralykovo.../install.sh | bash, což je sice taky hnusné, ale pokud uděláš zajímavý software a uživatelé ti budou věřit, tak to budou používat (na GNU/Linuxovém desktopu) a budou spokojení.

Takže kopat do klasických distribucí nebo do si stěžovat na lidi, kteří doporučují čistější řešení – nebo se na tohle vymlouvat – je celkem mimo.

[kralyk z abclinuxu]

Takže kopat do klasických distribucí nebo do si stěžovat na lidi, kteří doporučují čistější řešení – nebo se na tohle vymlouvat – je celkem mimo.

Moje kritika vychází ze zkušenosti s prácí na celkem široce používaném desktopovém softwaru (necítím potřebu se tady s tím nějak víc asociovat, dnes už na tom projektu nepracuju). Moje zkušenosti byla, že cílit na linux distra bylo oproti ostatním desktop OS dispropočně velký oser.

Samozřejmě je možné, že jsem měl jen smůlu nebo že za to mohlo něco jinýho... Nicméně Linus má zřejmě podobnou zkušenosti a podobně i p. Tůma. Takže jsem vyjádřil souhlas s tím jeho talkem. Rozvíjel jsem to dáke proto, že Heron napsal "Celkem by mě zajímalo, jak by se to mělo vlastně stát."

Toť vše. Ber nebo nech být, je mi to jedno.

[xkucf03]

Tak znovu:

• Nikdo ti nebrání přibalit všechny závislosti ke svému programu a distribuovat ho ve stylu MS Windows. Třeba jako ten ZIP nebo ve formě instalátoru, skriptu, který se rourou pošle do shellu atd. Nepotřebuješ k tomu tedy ani žádný Flatpak nebo Docker, stačí ti na to technologie a nástroje dostupné před dvaceti nebo více lety.
• Uživatelé MS Windows jsou zvyklí stahovat programy z webů jako Slunečnice nebo ze stránek autorů a proklikávat instalátory. Takže to, co jim poskytneš ty (i když nevyužiješ balíčkovací systém), nebude horší než to, co mají ve Windows.

Z toho vyvozuji závěr, že spor ohledně statického/dynamického linkování je celkem nepodstatný a ty příčiny malého rozšíření GNU/Linuxu na desktopu leží někde jinde.

[kralyk z abclinuxu]

Z toho vyvozuji závěr, že spor ohledně statického/dynamického linkování je celkem nepodstatný a ty příčiny malého rozšíření GNU/Linuxu na desktopu leží někde jinde.

Všimni si, že v bodech výše zmiňuju statický linkování až v tom posledním bodu za "např.". Shared linkování všeho samozřejmě samo o sobě není příčina, ale je to toho součást.

[xxx]

No body 1 - 4 tak nejak implikuje bod 5. 6 je tvoje uchylka vsude zminovat a 7 implikuje 5. Pricmez "lidi, kteří doporučují čistější řešení" jsou jednou z pricin bodu 7.

Nicmene, co se tyka bodu 5, tak kralyk navrhnul jistou standardizaci, ktera muze rozbit alespon nektere priciny bodu 5. (mizerné QA a neřízený vývoj).

Osobne si ale myslim, ze dokud nebudou vyvojari Linux na desktopu vyvyjiet pro jine vyvojare, adminy a jejich nebohe rodinne prislusniky, tak se nic nezmeni.

[xxx]

Eh, myslel jsme, ze 5 implikuje 1 az 4.

[trekker.dk]

Při koupi počítače uživatel dostane MS Windows, aniž by se ho na to v drtivé většině případů někdo ptal – prostě je nucen zaplatit licenci/výpalné Microsoftu v ceně počítače.

Při koupi počítače uživatel dostává službu "tady máte počítač a funguje" ve světě, kde jsou Windows stále de facto standardem. Nikdo se ho neptá, stjeně jako se ho nikdo neptá, jestli do toho chce RAM.

[xkucf03]

Tohle by bylo na samostatnou diskusi… Nicméně pointa toho komentáře byla v tom, že na podíl GNU/Linuxu na desktopu mají řádově větší vliv jiné věci¹ než nějaké balíčkovací systémy nebo statické vs. dynamické linkování.

_{[1] jako třeba fakt, že většina počítačů se prodává s předinstalovanými Windows (ať už s tím souhlasíme nebo ne)}

[kralyk z abclinuxu]

I kdyby to skutečně bylo tak nepodstatné, jak říkáš, co může distribuce udělat s tim, že výrobci předinstalovávají Windows? Nebo dokonce se státní podporou proprietárního SW? Kór když po nich chceš soustředění se na SW a ne na politiku.

Oproti tomu usnadnit život vývojářům a zlepšit spolupráci by mohli, pokud by byly ochotni vzít na vědomí ty problémy, které uvádí Linus. (A pokud na to mají prostředky, což, pravda, dost možná nemají...)

[j]

Vliv na to ma jen jedina vec ... nefungujou na tom hry.

Je to uz par let, ale v nekolika firmach sem si vybral pokusne kraliky, a dal jim tuxe. A pochopitelne sem jim k tomu nerek zcela umyslne vubec nic. Vetsina si myslela ze to je nejaka nova verze widli.

Slo o beznou kancl praci (opice, maily, nejaky erpecka ...). Takze typicky jediny co ten user chce, je mit na plose 10 ikon 10 aplikaci ktery pouziva (prehanim, 10 jich prevazne zdaleka neni) aby na ne moh kliknout a spustily se. No problem, vsem to vsechno fungovalo.

Vlastne nejvetsi problem kterej se resil, byly chybejici miny a solitaire

Z hlediska admina to pak fungovalo radove lip. Zminim trebas srackomet na tema offline files, roaming profiles, ...

---

Dete s tim guuglem dopice!

[Martin Tůma]

Problém je, že pokud se rozhodneš si něco radši napsat sám, místo existující knihovny (která tvůj problém řeší jenom z části a ještě blbě) hned se objeví nějaký hipster, který tě začne školit o NIH syndromu... K tomu, naučit se najít ten správný "prah citlivosti" nicméně existuje jednoduchý a efektivní tréninkový plán - vyvíjet SW (i) pro Windows. Pak totiž člověk velmi brzo zjistí, jký pain-in-the-ass každá další závislost jeho programu představuje. Protože jak by řekl klasik: "To není jako práce s npm/pip/rpm/apt, děti..."

Na druhou stranu někdy je to vyloženě Sofiina volba. Třeba mě by se docela hodilo v GPXSee mít podporu pro čtení PDF a jeden by řekl, že není nic jednoduššího, než použít Qt PDF modul. Jenomže Qt PDF, to je PDFium v "dárkovém balení" s prohlížečem, s dalším trilionem závislostí jako bonus... V hobby projektu si můžu dovolit být zásadový a takovou zrůdnost odmítnout, ale když za tebou v korporátu přijde manager, že tam to PDF chce...

To je změna k horšímu.

Jak pro koho. Pro vývojáře toho SW určitě ne a v "moderním vývoji" se, zdá se, píše hlavně pro ty vývojáře místo uživatelů... Sice to často vůbec nefunguje a integrace s desktopem je bídná, ale zase se to lépe vyvíjí...

[xkucf03]

Na druhou stranu někdy je to vyloženě Sofiina volba. Třeba mě by se docela hodilo v GPXSee mít podporu pro čtení PDF a jeden by řekl, že není nic jednoduššího, než použít Qt PDF modul. Jenomže Qt PDF, to je PDFium v "dárkovém balení" s prohlížečem, s dalším trilionem závislostí jako bonus... V hobby projektu si můžu dovolit být zásadový a takovou zrůdnost odmítnout, ale když za tebou v korporátu přijde manager, že tam to PDF chce...

Tohle je řešitelné tím, že danou funkcionalitu (a tím i závislost) vyčleníš do volitelného modulu, který si nainstaluje jen ten, kdo ho potřebuje. Ano, znamená to určitou práci, protože si musíš definovat rozhraní toho modulu, ale pořád je to lepší, než řešit to dilema, zda navýšit komplexitu i těm, kdo o to nestojí, nebo omezit funkcionalitu těm, kterým by se hodila.

Komplexita/závislosti představují náklad – a je žádoucí, aby tyto náklady byly volitelné (volitelný příplatek) a nenavyšovaly cenu základního produktu.

[xxx]

Tohle je uplny peklo pro vyvojare, jak si spravne identifikoval ale i pro uzivatele, ktery nevi proc mu nefunguje neco, co fungovat ma. Coz obvykle vyvojar pochopi, kdyz na nej zacne tlacit customer support, protoze si zakznici furt stezuji. A odpoved, ze si maji ninstalovat patricny modul je sice spravna, ale zkusenost, ze ten sw nefunguje uz zakaznikovi neikdo nerozmluvi. Bohuzel.

[Martin Tůma]

Tyhle rady teoretiků miluju. V praxi to pak vypadá tak, že půlka distribucí ty moduly vůbec nebalíčkuje a ta druhá neuvádí ve specfile ani ty moduly, které v té distribuci už jsou... Hněv uživatelů, že jim něco nefunguje si ale samozřejmě vyžere upstream.

[xkucf03]

Pár příkladů pro inspiraci:

• Postfix – např. si nemusíš instalovat MySQL a LDAP knihovny, pokud chceš mít uživatele atd. v PostgreSQL (nebo třeba v souborech, pak nepotřebuješ instalovat ani knihovnu pro PostgreSQL)
• JACK a LV2 – extistují spousty efektů a filtrů, některé z nich mají externí závislosti – a opět si instaluješ jen to, co používáš
• NetworkManager – pokud používáš jen OpenVPN, tak si nemusíš instalovat modul pro OpenConnect a jeho závislosti a naopak (totéž platí pro jiné VPN a obecně moduly)
• Okular – nenutí tě instalovat kancelářský balík, pokud chceš prohlížet jen PDF – pokud chceš v Okularu otevírat i kancelářské dokumenty (ODT), doinstaluješ si volitelný modul

Všechno to jsou ukázky běžně používaného softwaru na jedné z nejběžnějších distribucí (Debian). Opravdu to není nic exotického ani módní výstřelek posledních pár let.

A není to nějaký můj výmysl – je to normální způsob, jak dělat software. Jestli si o tom chceš přečíst od někoho jiného, tak pod tím mým článkem máš třeba PDF od Niklause Wirtha: A Plea for Lean Software.

[kralyk z abclinuxu]

Ale jo, když to dává smysl a autor to tak chce udělat, tak proč ne, moduly můžou být hezká věc. Ale nutit do toho každý trochu složitější projekt mi přijde nesmyslný.

[Martin Tůma]

Ale jistě, teoreticky to funguje skvěle, jenom v praxi to často přináší více problémů, než užitku... Že má Debian některé balíčky modulární nic neříká o tom, jak to ve skutečnosti funguje a kolik je lidí, kterým "nefunguje" VPN, protože zrovna nemají ten správný plugin pro Networkmanager.

Třeba mé osobní zkušenosti jsou, že takhle vypadá seznam distribucí s GPXSee a takhle seznam distribucí, s pluginem vektorových map pro GPXSee. Pro uživatele třeba takového OpenSUSE ta modularita zas taková výhra není, že?

[Heron]

To není žádná teorie a v praxi to ušetří opravdu velkou spoustu nainstalovaných balíčků (protože ty jednotlivé moduly mají ještě své závislosti) a tedy i potenciálních bezpečnostních problémů a každý admin se s tím setkává prakticky neustále.

Buď je program rozdělen do modulů a nebo je tam vícero balíčků dle konfigurace. Takže máme vim-tiny, vim, vim-nox, což je těžkotonážní verze, ale bez Xkek. A k tomu má vim ještě zabalíčkované často používané pluginy.

Nevím, jak jsou na tom kompilovaná distra linuxu, to jsem nikdy nepoužíval, ale na FreeBSD mám porty, kde před kompilací vybírám, které komponenty chci. A je to třeba rozdíl mít 20 závislostí nebo (defaultních) 600. Například u ffmpeg nepotřebuju podporu renderování fontů, což si s sebou tahá "půlku" Xkek nebo u ImageMagick nepotřebuju podporu PDF apod.

Takže je naprosto běžnou prací, že programy jsou nějakým způsobem rozděleny a je to spíš pravidlo, než teoretická výjimka.

[kralyk z abclinuxu]

a každý admin se s tím setkává prakticky neustále.

(...)

Například u ffmpeg nepotřebuju podporu renderování fontů, což si s sebou tahá "půlku" Xek

Asi budu muset znovu zopakovat, že se bavíme primárně o desktopu.

[Heron]

Chtělo by to nějakou jednoznačnou definici desktopu, ať teda víme, o čem se bavíme.

A ffmpeg používám kupodivu i na desktopu. Takže v konečném důsledku je úplně jedno, jestli se bavíme o desktopu nebo nedesktopu. Balíčkovací systém je furt ten samý a nedává smysl, proč, když to funguje (třeba) na serveru, by to nemohlo fungovat i na desktopu. Když to navíc pro mnoho programů funguje, ale tím se dostáváme kruhem na počátek diskuse.

Ona se ta modulární koncepce vůbec nevylučuje s uživatelskou přívětivostí. Na Windows je standardem, že instalátor nabízí defaultní variantu, kde stačí jen klikat na next a taky malé tlačítko na změnu konfigurace, kde si power user může zvolit jednotlivé komponenty.

On i ten příklad s tím prašivým Network Managerem má řešení, které se také používá. Pokud program zjistí, že uživatel chce použít nenainstalovanou komponentu, tak mu ji může nabídnout.

[_]

Pokud program zjistí, že uživatel chce použít nenainstalovanou komponentu, tak mu ji může nabídnout.

Přesně tak.

Není to tak dávno, co mi tu vyskakovaly nabídky, že si můžu doinstalovat Flash nebo nějaké proprietární (nebo patentově problematické?) kodeky. Je pak na každém, jestli si to nainstaluje nebo ne. Ale Kralík a Tůma by asi chtěli, aby ten Flash a všechny kodeky měli povinně nainstalované všichni, aby snad nějaký uživatel nebyl zaskočený tím, že něco nefunguje.

kolik je lidí, kterým "nefunguje" VPN, protože zrovna nemají ten správný plugin pro Networkmanager.

Aneb: my víme líp, co je pro vás dobré.

[Heron]

Není to tak dávno, co mi tu vyskakovaly nabídky, že si můžu doinstalovat Flash nebo nějaké proprietární (nebo patentově problematické?) kodeky. Je pak na každém, jestli si to nainstaluje nebo ne. Ale Kralík a Tůma by asi chtěli, aby ten Flash a všechny kodeky měli povinně nainstalované všichni, aby snad nějaký uživatel nebyl zaskočený tím, že něco nefunguje.

No hlavně je poněkud zvláštní se odkazovat na Windows (netvrdím, že to tady někdo z těch dvou uvedených, ale uváděl to přímo Linus), kde po instalaci neudělám vůbec nic, neotevřu PDF, nepustím si mp3 (už možná jo), nerozbalím archiv (pokud to náhodou není zip), nezobrazím obrázek, nepustím si film apod. Tak hlavně, že tam je stabilní api (které se nikdy neruší - a asi proto si každý program instaluje VC++ redist a directx, protože z nějakého prapodivného důvodu v W10 stále chybí potřebné C++ knihovny od MS), které mi dovoluje si pustit program z roku 1995. To jsem fakt rád.

Zatímco když nainstaluju distribuci linuxu ve výchozí desktop variantě, tak dostanu graficky pěkné prostředí a můžu tam dělat prakticky všechno hned po instalaci (a zbytek nainstaluju na tři kliknutí). Akorát nemůžu spouštět programy stažené z náhodných míst na internetu. Což já teda rozhodně nepovažuju za mínus.

[kralyk z abclinuxu]

Ale Kralík a Tůma by asi chtěli, aby ten Flash a všechny kodeky měli povinně nainstalované všichni, aby snad nějaký uživatel nebyl zaskočený tím, že něco nefunguje.

To je poněkud podpásový argument, vzhledem k tomu, že Flash byl 3rd party proprietární software, a navíc notoricky sračkoidní. Psal jsem, že proprietární software je trochu jiná kategorie a nemyslim si, že by byl dobrý nápad primárně navrhovat distribuce pro software jako byl Flash.

[_]

navíc notoricky sračkoidní

Tohle je značně subjektivní. Firmy, které nad tím vyvíjely svoje administrace, aplikace nebo hry nebo hráči těch her, kteří to dobrovolně používali, to zjevně za sračkoidní nepovažovali a mělo to pro ně přínos. (mimochodem svého času to byl prakticky jediný způsob, jak dostat do webové stránky video) Na druhé straně jiní uživatelé by si to na svůj počítač nikdy nepustili. Proto dává smysl ta volitelná instalace - i za cenu toho, že ten, kdo to potřebuje, si to bude muset explicitně a vědomě nainstalovat.

Jinak z licenčního hlediska je sice hranice mezi proprietárním a svobodným softwarem ostrá, ale v praxi už to tak jednoznačné být nemusí. Můžeš mít proprietární software (nebo třeba herní data), který se nikam nepřipojuje, nečte ani neupravuje žádné tvoje soukromé soubory a je ti něčím užitečný. A pak můžeš mít "svobodný" software od nějakého "náhodného člověka z internetu", který může pracovat pro tajnou službu libovolného státu (dosaď si dle své fóbie) a dává tam schválně backdoory, nebo pracuje pro mafii, prodává zero-daye nebo má jiné zlé úmysly a dělá to sám za sebe. Ono úplně neplatí, že open source = dobro a bezpečí, takže se nevymlouvej na to, že zrovna Flash je proprietární. Podobných sraček je i mezi svobodným/open softwarem dost a ne každý si je chce instalovat.

[kralyk z abclinuxu]

Proto dává smysl ta volitelná instalace - i za cenu toho, že ten, kdo to potřebuje, si to bude muset explicitně a vědomě nainstalovat.

Ano, souhlasim, že v případě Flashe to smysl dávalo.

Podobných sraček je i mezi svobodným/open softwarem dost a ne každý si je chce instalovat.

To je hezké, ale stejnětak ne každý autor softwaru chce rozmodulovávat svůj software ad nauseam. Někde mezi těmi extrémy musí existovat nějaký balanc.

[xkucf03]

rozmodulovávat svůj software ad nauseam

Tady bych si dovolil připomenout začátek diskuse:

Na druhou stranu někdy je to vyloženě Sofiina volba. Třeba mě by se docela hodilo v GPXSee mít podporu pro čtení PDF a jeden by řekl, že není nic jednoduššího, než použít Qt PDF modul. Jenomže Qt PDF, to je PDFium v "dárkovém balení" s prohlížečem, s dalším trilionem závislostí jako bonus... V hobby projektu si můžu dovolit být zásadový a takovou zrůdnost odmítnout, ale když za tebou v korporátu přijde manager, že tam to PDF chce...

Tohle je řešitelné tím, že danou funkcionalitu (a tím i závislost) vyčleníš do volitelného modulu, který si nainstaluje jen ten, kdo ho potřebuje. Ano, znamená to určitou práci, protože si musíš definovat rozhraní toho modulu, ale pořád je to lepší, než řešit to dilema, zda navýšit komplexitu i těm, kdo o to nestojí, nebo omezit funkcionalitu těm, kterým by se hodila.

Komplexita/závislosti představují náklad – a je žádoucí, aby tyto náklady byly volitelné (volitelný příplatek) a nenavyšovaly cenu základního produktu.

Navíc, jak jsem psal i v tom mém článku, když už máš to rozhraní, tak ti to umožňuje časem vyměnit implementaci. Takže se může začít s nějakou molochovitou knihovnou, která přibaluje kde co, a použije se to jako funkční prototyp, na kterém se odladí ten koncept (na čemž se budou dobrovolně podílet uživatelé, kteří o to stojí) a časem třeba někdo napíše či přinese lepší štíhlejší knihovnu.

[Martin Tůma]

Ale Kralík a Tůma by asi chtěli, aby ten Flash a všechny kodeky měli povinně nainstalované všichni, aby snad nějaký uživatel nebyl zaskočený tím, že něco nefunguje.

Nemyslím si, že by všichni měli mít nainstalováno všechno, ale stejně jako Linus si myslím, že v tom ekosystému balíčků distribuce prostě často fatálně selhávají. Buď na to dělení a udržování nemají zdroje, nebo si myslí, že ví mnohem líp než autoři SW, co jejich uživatelé chtějí. A to ani nemusí jít o diletanty z Debianu, kteří občas mají i pocit, že ví lépe než uživatelé, jestli chtějí entropii v SSH klíčích...

[Martin Tůma]

Chtělo by to nějakou jednoznačnou definici desktopu, ať teda víme, o čem se bavíme.

Nejlepší definice desktopu, co jsem kdy slyšel je, že desktop je počítač s Windows

A ffmpeg používám kupodivu i na desktopu. Takže v konečném důsledku je úplně jedno, jestli se bavíme o desktopu nebo nedesktopu. Balíčkovací systém je furt ten samý a nedává smysl, proč, když to funguje (třeba) na serveru, by to nemohlo fungovat i na desktopu. Když to navíc pro mnoho programů funguje, ale tím se dostáváme kruhem na počátek diskuse.

Balíčkovací systém je ten samý, ale uživatelé a jejich očekávání jsou zcela jiné. Admin serverů má úplně jiná očekávání/priority, než "běžný uživatel". A diskuze začala právě tím odkazem na Linusův talk: "proč se Linux neprosadil na desktopu mezi běžnými uživateli". Že tobě jako správci serverů (i na tvém desktopu) ten stav vyhovuje chápu, ale je to jaksi zcela mimo diskuzi. Ty prostě nejsi "běžný uživatel" o které tady jde.

Pokud program zjistí, že uživatel chce použít nenainstalovanou komponentu, tak mu ji může nabídnout.

To je zase takový krásný teoretický koncept, který to krásně řeší do té doby, než se to musí reálně udělat. Pak buď musí každý takový program mít vlastní repozitář s moduly, nebo pro každou jednu distribuci speciální kód, který interaguje s balíčkovacím systémem. Oboje dvoje je spousta zcela zbytečné práce, která samotný program nikam neposune.

[Heron]

Nejlepší definice desktopu, co jsem kdy slyšel je, že desktop je počítač s Windows

Tak jsem rád, že jsem to nemusel psát sám

A opravdu chceme, aby tahle vypadal linux? Widle jsou systém, které si jako koule na noze s sebou nese špatná rozhodnutí už někdy v dosu, kde jsou dodnes kompromisy "aby fungovaly programy, které potřebují admina a které si svoje data ukládají ne k userovi, ale do program files". Které sahají až někam k windows 95, kde byla podmínka spouštění dos her, které neběžely na NTčkách.

Windows jsou špatný systém, který vytvořil špatné návyky jak na straně uživatelů, tak na straně autorů software.

[kralyk z abclinuxu]

A opravdu chceme, aby tahle vypadal linux?

Za mě ne, Windows obecně nesnášim, ale neznamená to, že na nich je špatně úplně 100% komplet všechno.

[xkucf03]

A jakou tedy mají relevantní výhodu? Absenci balíčkovacího systému? Tak si ho na GNU/Linuxu odmysli a nepoužívej. Jak jsem ti tu už psal, můžeš dělat instalátory ve stylu Windows, všechno linkovat staticky nebo přibalovat vlastní .so knihovny. GNU/Linux v tomhle není o nic horší než MS Windows, umožňuje ti totéž (a mnoho navíc). Takže pokud bys měl pravdu, mohl by díky těmto instalátorům a statickému linkování navýšit podíl GNU/Linuxu na desktopu.

[kralyk z abclinuxu]

A jakou tedy mají relevantní výhodu? Absenci balíčkovacího systému?

Nn, to je IMO nevýhoda. I když člověk linkuje staticky nebo něco podobnýho, je fajn mít nějaký balíček a mít možnost rozumným způsobem tu věc odinstalovat. Za výhodu považuju např. celkem dobrou kompatibilitu napříč různými instalacemi (včetně binární).

Jak jsem ti tu už psal, můžeš dělat instalátory ve stylu Windows, všechno linkovat staticky nebo přibalovat vlastní .so knihovny. GNU/Linux v tomhle není o nic horší než MS Windows, umožňuje ti totéž (a mnoho navíc).

Jistě, však takovou cestou ten projekt ultimátně šel. Oficiální balíčky Flatpak, distribuční balíčky dobrovolníci v komunitě. Vzhledem k budgetu a alokaci lidí ani nic jiného nezbylo.

[kralyk z abclinuxu]

Admin serverů má úplně jiná očekávání/priority, než "běžný uživatel".

+1, vtipné je, že to klidně může bejt jedna a tatáž osoba. Třeba já Na servříku mam Debian a ten minimalistický, příp. modulární přístup mi tam celkem dává smysl.

Na desktop mi Debian moc smysl nedává, minimálně bych musel dělat něco takovéhohle nebo podobné kraviny. Díky bohu za Arch a AUR... a v poslední době k tomu přidávám ještě Nix (protože je lépe automatizovatelný než AUR a má spoustu balíčků).

[z_sk]

Debian je i na Deskopt. Vyberies si co chces a Debian je jedno z top distier. To co linkujes bezne uzivatel neriesi. Chces nemat problemy, das stable, auto-install kriticke aktualizacie a je po probleme.

[kralyk z abclinuxu]

Jo a ještě...

To není žádná teorie a v praxi to ušetří opravdu velkou spoustu nainstalovaných balíčků

Pokud řešíš, že na headless stroji nechceš Xka, tak určitě ano, ale to není téma diskuse. Moje zkušenost je, že počet balíčků se tím přístupem, kterej tady razíte s xkucfc, neušetří, naopak.

Case in point: Haskell balíčky na Archu. Někdo se zřejmě rozhodl následovat tu mantru, že jazykové balíčkovače jsou fuj hnus, velebnosti, a všechno musí bejt v distribučních balíčcích, mmkay. Takže ve chvíli, kdy se pokusíš nainstalovat například Pandoc (balíček), tak bude pacman chtít nainstalovat 126 balíčků z haskell ekosystému o celkově velikosti 362MB. Což je absurdní.

Samozřejmě, v té chvíli tady nejspíš začnete prosazovat ten modulární fašismus a řeknete, že Pandoc je antipattern a měl by správně bějt rozdělnej na hromadu malejch balíčků, nad kterejma já mam podle vás mudrovat a řešit, co z toho budu potřebovat a to pak instalovat. Což stejně nejspíš dospěje k tomu, že budu ručně jak kretén instalovat desítky balíčků jenom kvůli jednomu prográmku.

Tohle je přesně to, co nechci. Když instaluju tool jako je Pandoc, tak chci, aby to byl komprehensivní tool poskytující +- všechno, co umí, takovej švýcarskej nůž. A že některé z nich nebudu potřebovat? To mě naprosto netrápí.

Respektive lepší přírovnání než švýcarák je werkcajk. Myslíš si, že třeba takovej eletrikář si vždy před cestou za prací pečlivě zjistí, co všechno bude zákazník chtít, a následně si projde a vytřídí veškerý nářadí, každej šroubováček, aby měl jen to, co opravdu bude potřebovat? Ne. Prostě popadne celej vercajk komplet a nebude řešit, že ta bedna má třeba 20kg. Takovéhle věci bude řešit pouze u opravdu velkých, těžkých a/nebo vysoce specializovaných nástrojů.

Zpátky k pandocu. Co tedy s tim? No, vykašlu se na oficiální balíček a nainstaluju pandoc-bin z AURu, kterej je staticky nalinkovanej a nepotřebuje ke svému životu nic dalšího. Balíček má 67MB, což v téhle chvíli je značně méně, než když je to rozbalíčkováná do bambiliónu malích balíčků. Až budu mít takovejchhle balíčků nainstalovanejch 20, tak se třeba můžem bavit o nějaké deduplikaci závislostí, aby to žralo míň místa, ale pravděpodobně bude i tam dávat smysl deduplikovat jenom ty opravdu spoelčné a zároveň dostatečně velké závislosti.

Že to vede k bezpečnostním rizikům? Opět, upstream má trackování dependencí build systémem, ve zdrojáku si můžu zjistit strojově čitelnej seznam dependencí příkazem stack ls dependencies json a ten můžu následně automatizovaně konfrontovat třeba s nějakou CVE databází nebo podobně. Opět to je pouze otázka nasadit vhodnou automatizaci.

A kromě toho, fakt si někdo z vás myslí, že maintainer v distribuci každý den pečlivě sleduje desítky haskellovejch balíčků, jestli tam náhodou není něco špatně? Pravděpodobně to ultimátně je pro bezpečnost naopak horší než lepší.

Praxi stejně člověka mnohem pravděpodobněji ohrozí nějaký zapomenutý curly braces v libopenssl nebo nějaká taková podobná blbost v něčem naprosto základním.

[Heron]

Pokud řešíš, že na headless stroji nechceš Xka, tak určitě ano

Jestli ti tento příklad tak strašně vadí, tak si tam klidně dosaď to, že nechci s sebou tahat "půlku" gnome / kde, když si nainstaluju jeden program do i3wm. Některé programy to řeší celkem elegantně (třeba takové KDEnLive, ale tam je to imho dané tím, že je to i pro widle a tak si nemohli dovolit tahat celé kde a vybírají si jen určité QT knihovny), ale některé na to kašlou a jako závislost mají fakt celé DE. Nehledě ovšem na to, že takový blender, který (kromě dalších drobností ) obsahuje taky střižnu videí a má závislostí snad ještě méně.

Case in point: Haskell balíčky na Archu. Někdo se zřejmě rozhodl následovat tu mantru, že jazykové balíčkovače jsou fuj hnus, velebnosti, a všechno musí bejt v distribučních balíčcích, mmkay. Takže ve chvíli, kdy se pokusíš nainstalovat například Pandoc (balíček), tak bude pacman chtít nainstalovat 126 balíčků z haskell ekosystému o celkově velikosti 362MB. Což je absurdní.

A jak by se tohle vyřešilo pomocí jazykového balíčkovače? Pokud ten program ty balíčky potřebuje, tak se jich nainstaluje stejné množství ať již jazykovým balíčkovačem nebo z repa. A pokud je to v jednom případě výrazně horší, tak je potřeba najít chybu.

Respektive lepší přírovnání než švýcarák je werkcajk. Myslíš si, že třeba takovej eletrikář si vždy před cestou za prací pečlivě zjistí, co všechno bude zákazník chtít, a následně si projde a vytřídí veškerý nářadí, každej šroubováček, aby měl jen to, co opravdu bude potřebovat? Ne. Prostě popadne celej vercajk komplet a nebude řešit, že ta bedna má třeba 20kg. Takovéhle věci bude řešit pouze u opravdu velkých, těžkých a/nebo vysoce specializovaných nástrojů.

Jako každé přirovnání, tak i tohle kulhá. Elektrikář typicky neví kam jede, zapomenuté nářadí znamená poměrně velkou ztrátu času a hlavně, elektrikář má sadu nářadí, která se dá přirovnat k base system. Tj naprosto základní. A věř mi, že když je potřeba cokoliv jen trochu speciálního, tak pro to jede a ještě pro každou věc zvlášť (zažil jsem příklad, kdy potřeboval půl metru CY4 a jeho kolega mu opravdu přivezl přesně půl metru. Já nevím, doma mám "zbytek" asi 15m a když někde kousek potřebuju, tak to beru celé). Těch historek z natáčení mám coby předseda SVJ desítky.

Zatímco když mi něco chybí v systému, tak napíšu apt install něco a za sekundu dál pracuju. Nebo moderní editory typu VSCode na každý nově otevřený jazyk okamžitě nabízejí pluginy, stačí jeden klik. Ale ano, už jsem se setkal s kolegy, kteří mi nadávali za to, že na stroji není nějaký jejich essential balíček a že JÁ jim to tam mám při přípravě instalovat.

[kralyk z abclinuxu]

Některé programy to řeší celkem elegantně (třeba takové KDEnLive, ale tam je to imho dané tím, že je to i pro widle a tak si nemohli dovolit tahat celé kde a vybírají si jen určité QT knihovny), ale některé na to kašlou a jako závislost mají fakt celé DE.

Já nesouhlasim s tou interpretací, že to první je Správně™ a TakToMáBýt™ a to druhé je Špatně™. Je to tradeoff, oboje má nějaké výhody a nevýhody a každý autor si zváží, jestli chce investovat svoje prostředky do modularity a agnostičnosti k prostředí, nebo do něčeho jiného (příp. v jaké míře).

A jak by se tohle vyřešilo pomocí jazykového balíčkovače?

No vždyť to píšu o kousek níž...

zažil jsem příklad, kdy potřeboval půl metru CY4 a jeho kolega mu opravdu přivezl přesně půl metru

CY4 je materiál, ne nástroj.

Nebo moderní editory typu VSCode na každý nově otevřený jazyk okamžitě nabízejí pluginy, stačí jeden klik.

Ano ale ta věc si to řeší sama, má nějaký svůj balíčkovač mimo distribuční balíčky - myslel jsem, že to je Špatně™, podobně jako pip atd. atp.

[Heron]

Já nesouhlasim s tou interpretací, že to první je Správně™ a TakToMáBýt™ a to druhé je Špatně™. Je to tradeoff, oboje má nějaké výhody a nevýhody a každý autor si zváží, jestli chce investovat svoje prostředky do modularity a agnostičnosti k prostředí, nebo do něčeho jiného (příp. v jaké míře).

Jasně, uznávám, že toto je věcí názoru a pohledu na svět. Já uznávám filozofii, že dokonalé je to, odkud už není co odebrat. Coby systémák se vždy snažím o minimální množinu nástrojů, které řeší maximum situací.

Ano ale ta věc si to řeší sama, má nějaký svůj balíčkovač mimo distribuční balíčky - myslel jsem, že to je Špatně™, podobně jako pip atd. atp.

Já neříkám, že zrovna tato implementace je dobře, ale uvádím to jako příklad, kdy to pro uživatele může být naprosto elegantní i v případě, že se mu na počátku nainstaluje naprosto minimální prostředí. Ostatně některá distra třeba nabízejí instalaci nějakého balíčku, pokud se jej uživatel pokouší spustit. Tj vůbec není nutné tam mít na počátku všechno a přes to to uživatele nijak zvlášť neomezuje.

[kralyk z abclinuxu]

Já neříkám, že zrovna tato implementace je dobře, ale uvádím to jako příklad, kdy to pro uživatele může být naprosto elegantní i v případě, že se mu na počátku nainstaluje naprosto minimální prostředí. Ostatně některá distra třeba nabízejí instalaci nějakého balíčku, pokud se jej uživatel pokouší spustit. Tj vůbec není nutné tam mít na počátku všechno a přes to to uživatele nijak zvlášť neomezuje.

Ano, ale stejnětak zmiňuješ jako negativum, že na Windows chybí věci v základu.

Já myslim, že bychom se mohli shodnout, že to chce nějakou vhodnou míru. Samozřejmě teda různí lidé mají různé názory na to, co je ta správná míra.

Ještě se vrátim k tomu elektrikářovu základnímu werkcajku: Vidim jako negativum, že v linuxu něco takového chybí. Bylo by hezké, kdyby distribuce nabízely nějaký společný základ, i třeba do nějaké (rozumné) míry modulární. Ano, existuje POSIX a tak... ale pro potřeby desktopu to je zoufale málo. A distribuce se navzájem neshodnou ani na naprosto základních věcech, třeba TLS a certifikáty.

[Heron]

Ano, ale stejnětak zmiňuješ jako negativum, že na Windows chybí věci v základu.

Dávám to do kontrastu s tím, že někdo chce, aby bylo jedno sestavení programu funkční na věky věků a že OS má mít stabilní API. Widle mají tak stabilní api, že si programy stejně s sebou tahají dllka a instalují další knihovny od MS, protože se to nějak nevešlo do base OS o velikosti desítky GB. A ve výsledku tam po instalaci není vlastně vůbec nic.

A v OS, kde roky čtu, jak chybí api na všechno (přičemž polovina z toho je jen neznalost dotyčných), je od roku 1998 od instalace plně funkční prostředí pro uživatele.

Já myslim, že bychom se mohli shodnout, že to chce nějakou vhodnou míru.

Ale však jistě. Dyť je to jenom diskuse, z toho se nestřílí.

Bylo by hezké, kdyby distribuce nabízely nějaký společný základ, i třeba do nějaké (rozumné) míry modulární.

Jenže jaký by to měl být? I u toho elektrikáře je rozdíl, jestli spravuje 400kV pro ČEPS, 22kV pro místní distribuci, 6kV pro továrnu nebo 230V pro domácnosti. Stejně tak můžeme jít po jednotlivých "standardech" co se snaží prosadit a probrat si je všechny a rovnou si zopakovat, všechny flamy, co se za poslední roky kolem nich udály . Aneb minecraft nemá modapi a má tisíce modů už od alphy. Někdy prostě chybějící api vůbec nevadí.

[_]

Tohle je přesně to, co nechci. Když instaluju tool jako je Pandoc, tak chci, aby to byl komprehensivní tool poskytující +- všechno, co umí, takovej švýcarskej nůž. A že některé z nich nebudu potřebovat? To mě naprosto netrápí.

Právě k tomu se používají meta-balíčky, které samy nic neobsahují a jen deklarují závislosti. Takový balíček ti pod jedním názvem (takže instaluješ jen: apt install xxx a vše potřebné se dotáhne samo) poskytuje nějaký ucelený soubor funkčnosti. Dělá se to tak, aby soubor definovaný meta-balíčkem vyhovoval většině - ale pokud má někdo jiné potřeby, nikdo mu nebrání se na meta-balíček vykašlat a vybrat si ručně, co bude instalovat.

Většina lidí si pak nainstaluje třeba apt install kubuntu-desktop a dostane plnohodnotné desktopové prostředí + řadu věcí, které nepotřebuje. Ale ten, kdo to víc řeší, si vybere konkrétní aplikace a nemusí instalovat bloatware.

Myslíš si, že třeba takovej eletrikář si vždy před cestou za prací pečlivě zjistí, co všechno bude zákazník chtít, a následně si projde a vytřídí veškerý nářadí, každej šroubováček, aby měl jen to, co opravdu bude potřebovat?

To se ale nestalo samo od sebe. Rozhodně nestačí si v obchodě koupit kufr plný nářadí. Ten elektrikář musel pracně dointerovat k sadě nástrojů, kterou potřebuje, mnohokrát se musel vracet pro nástroj nebo materiál, mnohokrát si nadával, že toho tahá moc... až na základě zkušenosti si sestavil nějaký svůj individualizovaný kubuntu-desktop, který mu vyhovuje pro většinu zakázek. Ale stále to je modulární, není to pevně svázané a neoddělitelné - a občas si s sebou bere jen pár konkrétních nástrojů nebo naopak k tomu kufru přidá i něco navíc.

A jak už ti psal Heron - jet pro nářadí přes půl města je docela opruz a ztráta, takže to člověk moc nechce riskovat a radši si toho vezme víc. Ale zadat jeden apt install ... nebo dvakrát kliknout v Centru softwaru nic není.

[kralyk z abclinuxu]

Právě k tomu se používají meta-balíčky, které samy nic neobsahují a jen deklarují závislosti. Takový balíček ti pod jedním názvem (takže instaluješ jen: apt install xxx a vše potřebné se dotáhne samo) poskytuje nějaký ucelený soubor funkčnosti.

Super, takže řešení je další balíček. Nejdřív se to všechno rozebere na kousíčky a pak se u 95% uživatelů ty kousíčky zase složí dohromady metabalíčkem, a to celé jen proto, aby pár uživatelů mohlo v noci klidně spát s vědomím, že namjí v sysétmu ani .so-čko na zmar.

Tohle mi celé silně připomíná tzv. nanoservices, tj. když to někdo přežene s microservicama.

[deda.jabko]

Nevim, jestli se to zvrha vic v sikmou plochu nebo mlaceni slamennych panaku.

Nejdřív se to všechno rozebere na kousíčky a pak se u 95% uživatelů ty kousíčky zase složí dohromady metabalíčkem, a to celé jen proto, aby pár uživatelů mohlo v noci klidně spát s vědomím, že namjí v sysétmu ani .so-čko na zmar.

Za prve, rozdeleni na vice balicku ma i dalsi dusledky, napr. je jednodussi spravovat mensi oddelene balicky nez komplexni moloch, je rychlejsi/uspornejsi aktualizovat jeden balicek, nez cely velky moloch.

Nejdřív se to všechno rozebere na kousíčky a pak se u 95% uživatelů ty kousíčky zase složí dohromady

K tradicnim unixum od pradavna patrilo to, ze se nesnazi byt chytrejsi nez jeho uzivatele, a proto respektovaly i tech 5% uzivatelu, kteri chteji delat divne veci, protoze proto proste maji duvod.

Pokud chces operacni system, ktery bude vyladeny pro tech 95% uzivatelu, kup si Mac.

[xkucf03]

Za prve, rozdeleni na vice balicku ma i dalsi dusledky, napr. je jednodussi spravovat mensi oddelene balicky nez komplexni moloch, je rychlejsi/uspornejsi aktualizovat jeden balicek, nez cely velky moloch.

Kromě toho to má podobný vedlejší pozitivní efekt jako jednotkové nebo obecně automatické testy – donutí to autora se víc zamyslet nad návrhem, lépe si definovat rozhraní a lépe strukturovat software na menší samostatně nasaditelné/testovatelné části.

Naopak tam, kde si člověk/tým jen načrtne nějaké vnitřní balíčky (třeba package v Javě nebo namespace v C++), tak je dost těžké udržet tu disciplínu a po letech to zpravidla vede na špagetový kód, vznik nelogických vazeb a závislostí… korporátní vývoj, kde lidi pracují pod tlakem termínů, v tomhle bude asi hůř, ale ta tendence chodit zkratkami bude trochu všude.

K tradicnim unixum od pradavna patrilo to, ze se nesnazi byt chytrejsi nez jeho uzivatele, a proto respektovaly i tech 5% uzivatelu, kteri chteji delat divne veci, protoze proto proste maji duvod.

Navíc ta většina nemusí být takto drtivá a těch 5% skupin může být docela dost – a každá bude mít jiné zájmy. Často se říká něco ve smyslu: 90 % uživatelů používá 10 % funkcí… ale každý jiných 10 %. To je trochu nadsázka, ale v principu to platí a východiskem z takové situace je právě ten modulární návrh.

[kralyk z abclinuxu]

Za prve, rozdeleni na vice balicku ma i dalsi dusledky, napr. je jednodussi spravovat mensi oddelene balicky nez komplexni moloch, je rychlejsi/uspornejsi aktualizovat jeden balicek, nez cely velky moloch.

Huh? Vydat novou verzi software rozděleného na X balíčků je naopak náročnější (na byrokracii) než prostě publikovat jeden balíček. Podobně i pro mě jako správce svého systému je určitě jednodušší brát jeden software jako jeden balíček.

Samozřejmě to tak nemusí být vždycky, jak už jsem psal, ta modularizace může dávat smysl a může to být hezký řešení. Ale kdyby takhle bylo fakt všechno do maximální míry, tak bych měl nejspíš na počítači masivní DAG desítek tisíců balíčků bez šance se v tom vyznat.

K tradicnim unixum od pradavna patrilo to, ze se nesnazi byt chytrejsi nez jeho uzivatele, a proto respektovaly i tech 5% uzivatelu, kteri chteji delat divne veci, protoze proto proste maji duvod.

Bylo by hezké, kdyby ten respekt fungoval v obou směrech. Tj. nejen od upstreamu k uživateli, ale i obráceně. Takže když např. je někdo součástí té 5% menšiny (což je nás tady nejspíš paradoxně většina, akorát jsme každý v trochu jiné 5% skupince), tak by bylo fajn, kdyby si to uvědomoval, a taky to, že ten software nepádá z repozitáře sám od sebe a že pro upstream nemusí bejt úplně jednoduchý cílit na 20 různejch systémů, zejména pokud není financován megakorporací. Bohužel to úplně pravidlem není, naopak je běžný na ně nadávat jako na "prasiče" atd., viz tahle diskuse, případně všelijaké podobné věci jsem čítal (a stále čítám) v bugreportech apod. ...

[podlesh]

V hobby projektu si můžu dovolit být zásadový a takovou zrůdnost odmítnout, ale když za tebou v korporátu přijde manager, že tam to PDF chce...

Technická: v opravdovém koroporátu na do odpovíš: žádný problém, vyjedu seznam všech knihoven a jejich licencí, uvidíme co na to řekne právní oddělení.

Tím to vesměs skončí A pokud ne, tak se nejedná o opravdový korporát! Nebo se jedná o IBM, tam si dokáží vyjednat výjimku pro lokaje.

[petr_p]

Asi IBM zaměstnává neznalé právníky. Ti znalejší řeknou, že věty se „should“ jsou právně nevymahatelné, protože to není podmínka, ale jen pěkná prosba.

[podlesh]

Proto tam není should, ale shall.

[Martin Tůma]

V korporátu pracuješ kvůli prachům, ne kvůli ideálům, takže není důvod takové malichernosti řešit a bez rozpaků jdeš cestou nejmenšího odporu. Proto taky vypadá veškerý korporátní SW tak jak vypadá...

[xkucf03]

+1

Taky už jsem o tom psal jednou v blogu: Statické linkování?.

[kralyk z abclinuxu]

Ten odstavec je z většiny nepravdivý :-/

To ale nic neřeší, protože ty závislosti a komplexita tam jsou stále, jen nejsou vidět – o to je to vlastně horší. Jednak to vytváří falešný pocit jednoduchosti a jednak uživatel nebo správce těžko zjistí, z čeho se program skládá a které jeho části mohou být zastaralé a vyžadovat aktualizaci. Program je pak černá skříňka, o kterou se musí starat její autor (v případě svobodného softwaru se do role autora alespoň může přepnout i ten správce nebo uživatel, ale znamená to ruční zkoumání kódu a závislostí). Balíčkovací systémy oproti tomu fungují transparentně, poskytují nám jednotné rozhraní k instalaci i aktualizacím veškerého softwaru a strojově čitelný přehled o závislostech mezi balíčky (programy a knihovnami).

Moderní programovací jazyky mají svůj management závislostí a jsou schopné strojově čitelným způsobem, např. pomocí semver, specifikovat dependence + přidat "lockfile"/"sum file", který drží specifické verze + hashe závislostí v době, kdy autor program sestavoval a testoval. Takže máš možnost sestavit program s na bit stejnými závislostmi jako autor.

Neexistuje žádný rozumný důvod, proč by se tyto informace z upstreamu nemohly a neměly propagovat do distribuce. Distribuce stejně musí mít znalost o build systému daného softwaru, aby byla schopná ho sestavit, tudíž má k dispozici i tyto informace, a to ve strojově čitelné podobě. Proč to tedy nevyužít? Je to naopak automatizovatelnější a spolehlivější, než ten "tradiční" postup, kdy nějakej maintainer balíčku musí jít a ručně zjišťovat někde ve free-form dokumentaci, co má jakej software za dependence a kodifikovat to do balíčku.

Uživatel by měl mít celkem snadnou možnost stáhnout si zdroják balíčku a balíček si sestavit sám, přičemž by neměl být problém třeba nahradit nějaké dependence jinými kompatibilními. Např. cargo v Rustu má i přímo podporu pro ad-hoc nahrazování dependencí.

Tj. ty údajné výhody sdílených knihoven, které popisuješ, reálně existují pouze pro closed-source software. A ano, je samozřejmě fajn, když můžeš nějakému closed-source softu podstrčit jiný SO, ale nemyslim si, že by se linuxové distribuce měly primárně řídit closed-source softwarem.

[deda.jabko]

Moderní programovací jazyky mají svůj management závislostí a jsou schopné strojově čitelným způsobem,

Uff, to jsem se uklidnil, ze jeste dnes nekdo Javu povazuje za moderni jazyk. ;-]

V kazdem pripade mam k tomuto reseni znacne ambivalentni vztah. Myslenka je to v zasade dobra, ale ... velka skupina programatoru ma diky tomu snizeny prah, co je jeste rozumne. Potrebuji jednu jednoduchou funkci, pridam zavislost, co se muze stat? V konecnem dusledku pak mas i u banalniho projektu (diky tranzitivnimu uzaveru zavislosti) stovky knihoven, o kterych nevis, co vlastne delaji, kdo je udrzuje a zda je vubec udrzuje. Maven, npm (mozna i cargo) to proste stahlo, tak to bude spravne.

[kralyk z abclinuxu]

Uff, to jsem se uklidnil, ze jeste dnes nekdo Javu povazuje za moderni jazyk. ;-]

Maven IIRC neumí to zamykání? Nejsem si jistej. Ale ano, máš pravdu, umí to většina jazyků ... kromě C/C++ :-/ (a ano, vim, že existuje nějaká inicitavia kolem vcpkg a tak, ale AFAIK to ještě není úplně ono).

velka skupina programatoru ma diky tomu snizeny prah, co je jeste rozumne. Potrebuji jednu jednoduchou funkci, pridam zavislost, co se muze stat? V konecnem dusledku pak mas i u banalniho projektu (diky tranzitivnimu uzaveru zavislosti) stovky knihoven, o kterych nevis, co vlastne delaji, kdo je udrzuje a zda je vubec udrzuje. Maven, npm (mozna i cargo) to proste stahlo, tak to bude spravne.

Ano, to je bohužel pravda. I když si myslim, že stále zbývá nějak kvantifikovat, jak moc to vlastně vadí, respektive jak moc jsou aféry jako left-pad celkově ohrožující.

[podlesh]

V praxi je největší problém to, že ten tranzitivní uzávěr typicky obsahuje jednu knihovnu v několika různých verzích - a jenom jedna se dostane do výsledku. Pokud ty verze nebyly dostatečně kompatibilní, tak celá aplikace v náhodném okamžiku začne generovat zajímavé výjimky. Typicky po triviální opravě nějaké bugu, kdy už to celé dávno běží v produkci.

[petr_p]

Přidám, že upstreamová specifikace závislostí sama může obsahovat chyby. Co já jsem se nahlásil přebytečných, chybějících nebo špatně zařazených (build-time, test-time, run-time) závislostí. Moje zkušenost je, že dokud se upstreamu kód instaluje, tak vůbec nějaké závislosti neřeší. Vtipné jsou pak historky, kdy upstream zadefinuje minimální verzi, protože to je zrovna verze, co on má na systému, nebo protože ta verze opravuje nějakou bezpečnostní chybu, která na funkci programu nemá vliv, ale upstream touží spasit i ty, co o to nestojí. K pláči pak jsou historky s volitelnými závislosti, kdy upstream, balíčkář a uživatel (to už zní jak nějaký vtip) mají každý jiný názor na (ne)zbytnost dané funkcionality.

Teorie, že balení je překonané, že stačí nagenerovat balíčky automaticky z upstreamových dat, se objevily zhruba s příchodem Dockeru. Mohu vás ubezpečit, že i v Red Hatu se tímto směrem napnulo určité úsilí, ale ovoce (v této podobě) nikdy nepřineslo. Ukázalo se, že zákazníci jsou dvojího druhu: jedni používají přímo instalátor daného jazyka a jeho upstreamové zdroje a tudíž o přebalený kód nestojí. Druzí zase nechtějí používat upstreamové zdroje, protože upstream za nic neručí a tak chtějí kód přefiltrovaný distributorem, který zaručí bezpečnost, licence a opravy chyb. Mimochodem neznám jedinou distribuci, která by na automatické generování balíčků přešla. Nejdál je asi Gentoo, které doporučuje uživatelům generovat perlové balíčky nástrojem g-cpan. Ale skutečný důvod je ten, že se Gentoo snaží nepřidávat perlové balíky do distribuce, protože nemá, kdo by je udržoval.

[Martin Tůma]

Ono hlavně pokud se bavíme o desktopu, tak tam jsou všechny tyhle "systémy v systému" jako cpan (pip, npm, cargo, ...) zcela okrajová záležitost. Většina relevantního SW je psaná v tom "nemoderním" C/C++...

[kralyk z abclinuxu]

Uhh. Jenom krátkce: Nemyslim si, že by se měly balíčky generovat fakt plně automaticky, spíš jde o nástroje, které by to měly usdnadnit. Pokud se specifikace dependencí nepoužívá při buildu, pak samozřejmě obecně vzato bude nepřesná. Nevim o tom, že by se Docker používal pro balení desktop SW.

[petr_p]

Nemyslim si, že by se měly balíčky generovat fakt plně automaticky, spíš jde o nástroje, které by to měly usdnadnit.

Takové samozřejmě existují. S různou kvalitou. Obvykle si je udržují distributoři. Jedna z přidaných hodnot distribučního balení je, že někdo zkontroluje, že definice závislostí dává smysl.

Pokud se specifikace dependencí nepoužívá při buildu, pak samozřejmě obecně vzato bude nepřesná.

Ona se používá při buildu. Ale je špatně. Jen to někomu momentálně nevadí. Typicky nadbytečná závislost: její přítomnost nezpůsobí, že se balík nepřeloží. Ale dotahuje kód, který není potřeba. To je špatně, protože: prodlužuje se doba buildu; zvětšuje se instalace; někdo se o oni musí starat; až se závislost rozbije, zastaví to build/instalaci, která by jinak prošla.

Nevim o tom, že by se Docker používal pro balení desktop SW.

Docker možná přímo ne, ale třeba flatpack ano. Koncepčně je to to samé (archiv se souborovým systémem, mapování zdrojů z hostitelského systému, entrypoint pro spuštění, závislosti).

[kralyk z abclinuxu]

Ona se používá při buildu. Ale je špatně. Jen to někomu momentálně nevadí. Typicky nadbytečná závislost: její přítomnost nezpůsobí, že se balík nepřeloží. Ale dotahuje kód, který není potřeba. To je špatně, protože: prodlužuje se doba buildu; zvětšuje se instalace; někdo se o oni musí starat; až se závislost rozbije, zastaví to build/instalaci, která by jinak prošla.

Ok, ale tohle by mělo opět být ve většině případů automatizovatelné. Python, Rust, Go na to nástroje mají...

Asi to nebude neprůstřelné / stoprocentní a zejména nějaké pološílené Rube Goldberg dynamické konfigurace automaticky vyhodnotit nepůjdou, ale to je pak těžko zpracovatelné i pro člověka...

[petr_p]

Tohle právě není automatizovatelné. Obzvlášť ne u dynamických jazyků (různě zanořené evaly a poslepované řetězce). Ano, existují statické i dynamické analyzátory závislostí, distributoři je používají, jsou užitečné, ale opět ne stoprocentně. Zase tam musí být člověk, který posoudí, jestli daný kus kódu je relevantní. A nemusí vůbec jít o šílené konstrukce. Například člověku je jasné:

if ($operating_system == "Windows") { load "Foo"}

ale je pro analyzátor je to nerozhodnutelný problém. Stroji chybí informace, že daný balíček je pro Linuxovou distribuci a že proměnná $operating_system asi nebude Windows, takže dávat Foo do závislostí nemá smysl. Statická analýza bude tvrdit opak, protože vidí klíčové slovo load. Dynamická analýza asi nikdy neusoudí, že by ta závislost byla potřeba, ale ta obecně nechytne spoustu „okrajových“ případů, protože dost kódu se počas testů nikdy neprovede.

[z_sk]

Možno sa mýlim, ale pri statickom linkovaní sa do výslednej binárky dostane zo statickej knižnice len kód, ktorý sa skutočne používa. Nie? Takže ideálne by podľa mňa nebolo prifariť celú statickú C knižnicu, ale len ten jeden symbol. Nie je mi jasné, kde sa vzal ten (t)ext funkcie stat() na stroji B a prečo sa na rovnakom mieste nemôže zobrať aj na stroji A.

Co pozeram ten vystup "nm library_static.so", tak pribalilo staticky iba stdio.

[Nitemedia s. r. o.]

Omlouváme se, musel byste psát hovna o Covidu a hrát si na experta ve dvaceti oborech, abyste zde měl nenulové hodnocení zápisku.

Registrovaní uživatelé jsou píče, dal bych dobré hodnocení, kdybych se chtěl registrovat. Díky.

[Gréta]

sem mu to teda jakoby lajkla zatebe ale stejně mě děsně vadí žeto je jenom takovej copypaste z terminálku třeba ten zdrojáček sem moch bejt vloženej dotoho <pre> tagu a nemuselo to bejt jako cat a taky to mohlo bejt jakoby víc vokomentovaný cose jakoby tam děje s nějakým malilinkatým ůvodem cože se jako bude vůůůbec dělat a tak.... ;D ;D

ale jako jo furt lepšejší než covid toho si eště jako byužijem dost napodzim možná :D ;D

[xkucf03]

Nedávno jsem narazil na cosmopolitan libc, který jde ještě dál. Snaží se být jako Java – přeložíš jednou, spustíš kdekoli.

Ale osobně mi to k nativním binárkám moc nesedí – podle mého to má dost okrajové využití a většina softwaru by se měla šířit přes distribuční balíčky pro danou platformu. Ty přenositelné nativní binárky si pak s sebou musí táhnout tu překladovou vrstvu/abstrakci (zatímco kdyby to byl bajtkód, tak k němu se běžně běhové prostředí nepřibaluje a využívá se to, které je nainstalované na daném systému).