Dotaz: Univerzálnost zdrojových kódů

[DWD]

Hotový balík můžeme používat jenom pro takovou distribuci a verzi Linuxu, pro kterou je udělaný, protože je kompilovaný proti knihovnám, které jsou v tomto Linuxu. Narozdíl od zdrojového kódu, který ještě není kompilovaný. Ten je možné použít pro různé Linuxy, protože se to vždycky nakompiluje proti takovým knihovnám, které tam jsou. Zdrojový kód je proto univerzální a přizpůsobuje se to konkrétnímu Linuxu až při kompilování nebo výrobě balíku. To se aspoň všude tvrdí. To, že je narozdíl od hotového balíku použitelný pro všechny Linuxy. Ale začínám o tom pochybovat, tak jsem se chtěl zeptat, co je na tom pravdy. Začínám se zajímat o kompilaci a o balení balíků ze zdrojových kódů. Během toho si to vždycky vyžádá nainstalovat nějaké balíčky, většinou devel-knihovny a jiné věci. Často to po nás chce doinstalovat i určité verze těch balíků. Proto je dost pravděpodobné, že takový balík v naších repozitářích ani nebude. Zdrojový kód potom může být pro některé Linuxy nepoužitelný. Kde je potom ta univerzálnost zdrojových kódů? Nebo aby takový zdrojový kód byl pro nás použitelný, museli bychom chybějící vyžádané balíčky získat z dalších zdrojových kódů. Tyto další zdrojové kódy si taky můžou vyžádat něco, co v repozitářích nemáme a tak můžeme nakonec překompilovat třeba i půlku systému. Potom místo, abychom zdrojový kód programu přizpůsobovali našemu Linuxu, tak přizpůsobujeme Linux zdrojovému kódu programu. To je potom to samé, jako pokoušet se instalovat balík, který není určený pro naši distribuci nebo verzi Linuxu. Taky si to vyžádá závislosti, které v repozitářích nemáme, ty bychom taky řešili balíkama z jiného Linuxu, ty si taky něco vyžádají a tak dále. Nakonec překopeme skoro celý systém. Nevidím v tom rozdíl. Při zpracovávání zdrojových kódů taky v hodně případech překopeme i polovinu Linuxu.

Odpovědi

[rADOn]

Mas v tom peknej hokej, jako obvykle si pletes balickovani a kompilovani.

…protože se to vždycky nakompiluje proti takovým knihovnám, které tam jsou…

Zapominas na to nejdulezitejsi - musis mit takovy knihovny kterym kompilovany program rozumi. Pokud se nevratnym zpusobem zmeni API, musis program prepsat aby novemu API rozumel. API je definovany v hlavickovych souborech - to jsou ty -devel balicky. Kdyz ti to proti nim zkompilovat nejde, neznamena to ze by kompiler nemohl udelat binarku, ale ze by takova binarka nesla slinkovat a tudiz by byla na prd. Zdrojak tedy neni univerzalni, je ale mnohem flexibilnejsi, protoze API knihoven se (pokud je nepisou prasata) meni mnohem mene nez ABI binarek. Krome toho pri kompilaci muzes obvykle linkovani nekterych knihoven uplne zrusit - pokud funkci kterou poskytuji nepotrebujes a program s tim pocita.

Strucna verze: Je to slozity. Zvykni si. Kdyby to bylo jednoduchy, zadny balickovaci systemy by nebyly potreba.

[fraxinus]

Áno. Je to skutočne tak. Týka sa to ale len jazykov ktoré kompilujú do natívneho kódu (C, C++, Pascal). Ak ti to vadí, mohol by si prejsť na jazyky ktoré kompilujú do nejakej virtual machine napr Java, alebo prejsť na interpretované jazyky (JavaScript, Perl, PHP, ...). V tom prípade je jedinou podmienkou mať runtime VM ako vyžaduje autor softvéru resp. rovnaká verzia interpretra. Ovšem aj tam môže nastať prípad že máš program pre Perl 0.1 z roku 1987 a tak starý interpreter už na tvojom OS nie je podporovaný. Ďalšou možnosťou je virtualizovať alebo emulovať danú architektúru (dosbox).

Majme príklad. Program Foo 1.0 vytvoril niekto v roku 1993. Používa knižnicu libbar-0.1.2. Potom vývoj programu Foo ukončil. Dnešná libbar má verziu 2.5.8 a má už dávno úplne iné API. Ty chceš nejakým spôsobom rozbehať program Foo 1.0 ale na tvojom systéme libbar-0.1.2 už nerozbeháš lebo používa registre ktoré boli len na 286-tkách. V tom prípade sa to naozaj nedá.

Ak máš nejaké súčasný OS s podporou 2 roky a chceš rozbehať program ktorý vyžaduje knižnicu ktorú daný OS nepodporuje (a je jedno či je to knižnica z pred dvoch rokov alebo z pred 20tich) tak ten systém to neumožňuje. Každý operačný systém obsahuje len istú mieru spätnej kompatibility pretože udržiavať viacero verzií je extrémne náročné.

Proste sa s tým zmier. Alebo prejdi na OS ktorého hlavným princípom je spätná kompatibilita všetých programov a všetkých knižníc od verzie 0.1 až po súčasnosť. Môžeme ti pomôcť s konkrétnymi problémami ale to je asi tak všetko.

[DWD]

Jestli tomu dobře rozumím, tak žádný program není na pořád. To jsem měl vědět hned, než jsem ten počítač kupoval. To bych se na všechny počítače vybodnul. V tom případě nemělo cenu si počítač pořizovat. Měl jsem se vykašlal na celý počítač hned a místo používání počítače jsem si měl najít jiný způsob. Já potřebuji něco, na co se můžu spolehnout, že mi bude fungovat pořád nebo když se zkazí, můžu kdykoliv vyměnit a funguje dál. Prostě něco, na co se můžu spolehnout, že můžu kdykoliv použít. A ne něco, co mi může být kdykoliv znemožněné používat. Například jsem chtěl některé věci řešil pomocí počítače. K tomu bych potřeboval nějaké programy, které by to uměly. Pracně si zjistím, které programy umí to, co potřebuji, seženu je, naučím se s nimi zacházet, všechno nastavím, navrhnu a se vším si dám hodně práce. Budu ty programy potřebovat, protože všechno budu mít postavené na tom. Později, až mi přestane fungovat počítač, budu muset koupit nový. Stejný počítač už neseženu, už budou novější typy a proto operační systém, který mám, mi do toho nového počítače nemusí pasovat, kvůli podpory hardwaru. Proto budu muset vyměnit taky operační systém za nový. V novém operačním systému zase nebude možné rozchodit ty programy, které potřebuji a nepomůžou ani zdrojové kódy, ze kterých bych buď kompiloval nebo vyráběl balíky. Musel bych sehnat nové verze těch programů. Ale co když nové verze těch programů mi nebudou vyhovovat nebo dokonce nebudou existovat vůbec, protože budou ukončené. To bych byl v pytli, protože bych nemohl používat programy, na kterých bych byl závislý. Byl bych na nich závislý, protože bych měl všechno postavené na nich. Všechno, co jsem za celou dobu pracně postavil na počítačích, by šlo do .... Vymstilo by se mi to, že bych měl všechno postavené na počítačích.

V takovém případě, že programy nejsou na pořád, nemá cenu něco řešit pomoci počítačů a mít něco postavené na počítači. V tom případě budu muset zavrhnout dělat něco pomoci počítačů a pomocí softwarů. Budu muset s počítačem skončit. Budu si muset zavčasu najít za počítače náhradu. Něco, co bude umět to, co potřebuji a přitom je na to větší spolehnutí, než na počítač a software.

[chrono]

Len málo programov komunikuje priamo s hardvérom. Väčšina knižníc (v konečnom dôsledku) potrebuje len glibc, alebo podobné veľmi často používané knižnice a tie sú buď stabilné, alebo nie je problém mať v počítači viac verzií, takže ak sa uspokojíš so starou verziou programu a nevadí ti, že budeš musieť mať nainštalovaných viac verzií nejakej knižnice, tak by problém nemusel nastať (navyše nie je problém všetko potrebné nainštalovať do nejakého adresára, takže staré a nové verzie knižníc, konfiguračných súborov... nemusia byť v rovnakých adresároch.

Inak skôr či neskôr sa pravdepodobne presadia procesory, ktoré nebudú spätne kompatibilné s procesormi 8086 a preto prestane fungovať obrovské množstvo starých programov, takže už je asi najvyšší čas hľadať si za počítač nejakú náhradu (alebo zarobiť strašne veľa peňazí a môžeš platiť niekoho, kto sa postará o to, aby nejaký starý program fungoval aj na novom počítači, s novým OS, novými knižnicami..., to sa samozrejme ľahšie robí v prípade, keď pre ten program existujú zdrojové kódy, takže kopec shareware, freeware... bez emulátorov prestane fungovať úplne).

[DWD]

Majme príklad. Program Foo 1.0 vytvoril niekto v roku 1993. Používa knižnicu libbar-0.1.2. Potom vývoj programu Foo ukončil. Dnešná libbar má verziu 2.5.8 a má už dávno úplne iné API. Ty chceš nejakým spôsobom rozbehať program Foo 1.0 ale na tvojom systéme libbar-0.1.2 už nerozbeháš lebo používa registre ktoré boli len na 286-tkách. V tom prípade sa to naozaj nedá.

Problém takového typu by se nemusel stát u programu, které nepoužívají žádnou knihovnu, ale mají všechny funkce, které používají, obsažené přímo v tom programu. Je to pravda?

[pitomeczech]

Problém takového typu by se nemusel stát u programu, které nepoužívají žádnou knihovnu, ale mají všechny funkce, které používají, obsažené přímo v tom programu. Je to pravda?

Fungují do té doby, dokud se zásadě neobmění pro ten program důležitá část v OS.

V každém případě OpenSource kód si můžeš upravit i za 20let a navíc si můžeš zkontrolovat jestli v něm není škodlivý kód. Nechci dělat chytrýho taky nejsem programátor ale tohle chápu. Problém bude spíše v nás!

[VSi]

Na druhou stranu za 20 let už ten kód nemusí jít zkompilovat aktuálními verzemi kompilátoru, nebo bude třeba použít všechny knihovny z doby, kdy vznikal, kód, protože API knihoven se mezitím nekolikrát změnilo. V takovém případě může být nakonec jednodušší to celé napsat znovu, protože na ten program můžou být kladeny požadavky na spolehlivost, a k tomu nestačí, že se ho "povede zkompilovat", ale musel by se nejspíš projít celý kód.

Jako problém (v některých případech) linuxu obecně vnímám to, že není definována nějaká základní skupina knihoven vč. jejich API, která by byla na všech distribucích dostupná. Samozřejmě to neznamená zamrznutí na aktuálních verzích, jen by v případě změn API musela zůstat zachována i ta stará verze jako nějaká vrstva kompatibility.

Na linuxu (na aktuální verzi distribuce) je problém snadno použít 5 let starou verzi aplikace, která se mezitím vyvíjela. Můžu jí chtít použít protože obsahuje nějaké funkce, které v novější verzi nejsou, nebo z jiného důvodu. Stejně tak je problém snadno (kdyby stačilo znovu zkompilovat, tak je to ještě OK, ale narazíme na nekompatibilitu knihoven, tj. nutnost část aplikace přepsat) nainstalovat dvě verze téže aplikace najednou.

Je sporné, jestli je takový přístup vhodný (viz nedávná diskuse ohledně statické kompilace programů). Pro opensource aplikace, které jsou trvale udržovány v repozitářích distribucí je současný stav na linuxu perfekrní a v podstatě bezproblémový. Ale pro málo používané nebo unikátní věci, co někde 10 let běží a pak je chci na novém systému, to není úplně vhodné a vznikají problémy. To samé uzavřené aplikace. Můžete sice říkat, že kdyby byly otevřené tak by to bylo lepší a vyřešilo by to pomalu všechny problémy světa, ale prostě uzavřené věci tu z nějakého důvodu jsou, v reálném světě se používají v obrovské míře, a jen tak se to ai nezmění.

Přístup MS Windows je podle mě o dost lepší pro uzavřené aplikace, nebo pro ty případy co jsem zmínil – možnost snadné instalace velmi staré verze od které mi stačí instalátor, mít nainstalováno více verzí nějaké aplikace také nebývá problém. Je fakt, že programy vytvořené pro Windows 95 lze většinou spustit i na nejnovějších Windows. Na druhou stranu pokud to nejde, tak oprava ne bez zdrojového kódu nemožná. Je ale třeba si uvědomit, že v praxi je realizace takové opravy často utopická věc.

Microsoft se hodně snaží o zpětnou kompatibilitu, na linuxu se to bere stylem "všechno překompilujeme, a když bude třeba upravíme zdrojáky, aby to chodilo" (ale už se nemluví o tom, že tenhle přístup nejde použít pro uzavřené nebo málo používané aplikace). Chtělo by to nějak spojit výhody obou přístupů.

[chrono]

Na linuxu (na aktuální verzi distribuce) je problém snadno použít 5 let starou verzi aplikace, která se mezitím vyvíjela. Můžu jí chtít použít protože obsahuje nějaké funkce, které v novější verzi nejsou, nebo z jiného důvodu. Stejně tak je problém snadno (kdyby stačilo znovu zkompilovat, tak je to ještě OK, ale narazíme na nekompatibilitu knihoven, tj. nutnost část aplikace přepsat) nainstalovat dvě verze téže aplikace najednou.

To je pravda len čiastočne. Keď program používa knižnice, pri ktorých si autor dá záležať na spätnej kompatibilite, tak sa dá používať aj starý program.

Napr. práve teraz som skúšal program gftp z Mandrake 10 (skompilované to bolo 18. januára 2004) a stále funguje aj keď mám všetky knižnice, ktoré používa, v najnovšej verzii (používa napr. GTK+2, zlib, pcre, libxml2, kopec X knižníc..., jediná špeciálna knižnica, ktorú to potrebuje je OpenSSL-0.9.7, ale asi mám nainštalovanú nejakú veľmi starú binárku, ktorá tú knižnicu potrebuje, takže mi to po rozbalení .rpm súboru funguje).

Funguje mi aj gftp z Mandrake 8 (skompilované 27. apríla 2001). Tam je výrazne menej závislostí, špeciálna knižnica je tentoraz GTK 1, ale tú knižnicu mám nainštalovanú kvôli XMMS, takže aj tá verzia mi funguje po rozbalení balíka.

Samozrejme je kopec knižníc, pri ktorých autorom vôbec nezáleží na spätnej kompatibilite a pri zmene API dokonca ani nezmenia verziu, takže je dosť veľký problém mať nainštalovaných viac verzií tej knižnice, ale také niečo sa (našťastie) pri používaných knižniciach stáva málokedy.

[Martin Tůma]

Jako problém (v některých případech) linuxu obecně vnímám to, že není definována nějaká základní skupina knihoven vč. jejich API, která by byla na všech distribucích dostupná. Samozřejmě to neznamená zamrznutí na aktuálních verzích, jen by v případě změn API musela zůstat zachována i ta stará verze jako nějaká vrstva kompatibility.

Linux ale takovou standardní množinu definovanou má - POSIX

To, že jiné, "běžnými programy" používané, knihovny mění svoje API už je jiná věc. Ale to není problém linuxu, ale autorů té knihovny a je to na platformě nezávislý problém. I linux umožňuje statické linkování nebo použití vlastních verzí dané knihovny, které jsou distribuovány s programem samotným jako se používá ve Windows.

[VSi]

Ano, o POSIX vím, ale podle mě se ukazuje, že pro desktopové a jiné používané aplikace je POSIX samotný "málo". Jako minimální nízkoúrovňový standard, který vyhoví pro celé spektrum nasazení linuxu je to vyhovující.

Představoval bych si, že věci jako openssl, grafické toolkity apod. by měly vždy v určitém okamžiku vydanou "stabilní verzi" se stabilním API. A byla by "jistota" že serverové a desktopové distribuce budou mít veškeré verze těchto knihoven od nejstaší až po aktuální. Ty staré verze by mohly být realizované jen jako vrstvy kompatibility nad těmi novými. Nemusely by být nutně všechny verze nainstalované, ale měla by být jednoduchá možnost, jak doinstalovat určitou verzi od každé knihovny. Záleží jak se které věci rychle vyvíjí, ale ty verze by mohly být třeba po 1-2 letech. Neznamená to, že jedna verze by byla "zmražená", jen by se nesmělo měnit API. Teoreticky je tohle možné už dnes, ale problém je v tom, že API knihoven se mění chaoticky a možná zbytečně často, a pak distribuce nemají balíčky pro starší verze knihoven, protože API se měnilo každou chvíli a muselo by jich být strašně moc.

Samozřejmě by tohle autorům knihoven nebo správcům distribucí přidělalo dost práce, protože při změně API knihovny by se musely udržovat ty kompatibilní vrstvy, aby všechny starší verze API fungovaly. Možná je to úplně proti ideologii současných distribucí linuxu, která mi přijde jako "každý si může dělat co chce, to je hlavní. že je v tom bordel, to až tak nevadí". Možná se tohle snaží změnit projekt Linux Standard Base?

Upozorňuji, že moc do hloubky tomu nevidím, takže jsem možná napsal nesmysl. Ale vycházím z toho, jak přibližně to funguje na Windows, kde si většina aplikací vystačí s Win API, popř. dotNET, u kterého je teprve 3. verze. Jistě, že má konkrétní podoba WinAPI a dotNET hromadu problémů, ale ideově mi to přijde jako dobré řešení.

[Martin Tůma]

To že Windows jsou na tom se zpětnou kompatabilitou mnohem lépe než linux neni žádný veřejný tajemství¹ a je to taky jeden z hlavních důvodů, proč pro linux neexistuje spousta komerčního SW. Otázka ale je, jestli to při stylu vývoje linuxu jde dělat stejně a zda to vůbec chceme.

1) Vzpomínám si dokonce, jak jsem někdy v roce 2007 pro lazení školního programu na SOJe používal debuger z roku 1987! Binárku z roku 1987!!!

[Jiří J.]

No kompatibilita na nějaké základní úrovni tam je, ale nepřešel jsem z win7 na winXP kvůli hrám jen tak bezdůvodně, na win7 jich spousta nefungovala ani v "režimu kompatibility"

[fraxinus]

Problém takového typu by se nemusel stát u programu, které nepoužívají žádnou knihovnu, ale mají všechny funkce, které používají, obsažené přímo v tom programu. Je to pravda?

Vobec nie. Co ak libbar-0.1.2 obsahovala zapis udajov programu Foo na 5.25" disketu. Dneska sa uz diskety ani nepouzivaju. Keby bol program skompilovany staticky, resp. ten program by si riesil zapisovanie na 5.25" disketu po svojom, dnes uz by to nefungovalo vobec.

A tu pekne vydno vyhody dynamickeho linkovania. libbar dajme tomu obsahuje jedinu funkciu a to ZapisDataProgramuFooNaDisketu. Dnes po 20 rokoch staci napisat "falosnu libbar" kde bude funkcia ZapisDataProgramuFooNaDisketu ale naprogramujes to tak aby tie data ulozil na disk alebo na usb kluc. Potom by teoreticky nebolo treba prekompilovat program Foo lebo on len vola tu funkciu a je mu jedno co sa tam s tym deje.

Inak nic nie je vecne, to vedel uz Dzingischan. Povedz o aky problem ide, mozno poradime konkretne. Ak by som napr. robil casovu schranku tak pocitac je fakt nevhodny. Ziaden bezny pocitac 200 rokov nevydrzi. Pozri sa ale na sondu Voyager. Vypustili ju v roku 1977 a po 33 rokoch ten pocitac stale funguje. A softver na nom menili uz mnoho krat.

[Dan Horák]

V Linuxovém světě existují 2 věci, které se snaží s různou úspěšností tento problém řešit - LSB a enterprise distribuce.