Statické linkování balíků (diskuse)

[chrono]

Vyskúšaj si niekedy skompilovať nejaký program kompletne staticky a potom prídeš na to, že na DVD by sa takých programov príliš veľa nezmestilo (a samozrejme sú tam aj iné, pravdepodobne ešte vážnejšie problémy).

Navyše by nastal problém s konfiguračnými súbormi (pretože sa stáva, že novšia verzia nejakej knižnice/programu má mierne inú konfiguráciu). To by si samozrejme mohol riešiť tak, že by každý program mal vlastné konfiguračné súbory, ale potom by si všetko musel nastavovať pre každý program a každú verziu zvlášť (a pochybujem, že by to niekoho bavilo dosť dlho na to, aby ocenil nejaké výhody staticky kompilovaných programov).

[default]

Vyskúšaj si niekedy skompilovať nejaký program kompletne staticky a potom prídeš na to, že…

…že spousta z nich vůbec nejde zkompilovat. Protože třebas ty knihovny "vespod" závisejí na proprietárních knihovnách či aplikacích. Zářným příkladem budiž Javí knihovny, které dost často závisí na WebSpherách, WebLogicích a tak podobně.

[Miloslav Ponkrác]

Já si vše pro sebe kompiluji staticky. Mám svůj seznam knihoven, které obecně v systému budou a jinak vše ostatní přikompiluji statická kompilace.

Na Windows to dělám rovněž s tím, že pouze systémové knihovny jsou jisté. Nicméně Windows jsou logičtější tím, že sdílené knihovny kernel Windows přednostně tahá ze stejného adresáře jako je binárka aplikace teprve pak je hledá jinde. Takže pokud program nasadíte do jeho adresáře a našoupnete mu tam správné knihovny a verze, pak žádné závislostní peklo nevzniká.

Na Linuxu to jde též, ale není to jeho přirozené chování a obecně se agituje, že je to špatný nápad. Linux vše řídí jako síť o stovkách tisíc počítačů s velkoadministrátorem, což pro osobní počítač není vždy ideální volba.

Sám si postupně kompiluji základní unix utility pro Windows aby na ničem nezávisely. Stejně tak jakýkoli program, který přeložím je pokud možno statický.

Čím více programů máte dynamicky a závislostně pospojovaných, tím větší peklo v tom, tím hůře se to udržuje a tím spíše si zneprovozníte mnoho programů výměnou jedné knihovny. Základních systémových a široce sdílených knihoven má být naprosté minimum.

Dynamické závislosti jsou geniální třeba v mém routříku s MIPS procesorem s Linuxem, kde běží pár prográmků, je tam 32 MB flaska, kde to sedí a 8 MB RAM.

Není pravdou, že při statické kompilaci by se vešlo pár programů na DVD. Staticky zkompilovaná binárka nenatáhne celý obsah .so, ale jen to co potřebuje. Navíc vypadnou interface obskurnosti mezi .so a binárkou, takže i to zmenší program. Navíc kmpilátor může lépe optimalizovat, některé věci duplikované kvali rozdělení do více souborů jsou tam jen jednou. Pokud je dobrý kompilátor a lidé přestanou notoricky blbě nastavovat kompilátor při kompilaci (nenechají tam debug a jiné informace), pak na DVD umístíte tisíce programů a ještě zbyde.

Já dávám přednost tomu, aby aplikace tvořila uzavřený ekosystém. Jedno jestli staticky zkompilovaná, nebo se soukromými knihovnami, které používá jen daná aplikace a nikdo jiný. Jakékoli závislosti jsou vedeny pouze na systémové knihovny, či na standardizované knihovny, které jsou zaručeny v systému.

[Filip Jirsák]

Jak to řešíte v případě, kdy vyjde oprava některé z těch knihoven? Všechno překompilujete znova?

[Miloslav Ponkrác]

A jak to řešíte, když vyjde oprava programu? Nebudete ho také znovu překompilovávat?

Vážený pane, opravy programů, pokud se tomu někdo věnuje přicházejí zhruba tak často, spíše častěji, než opravy knihoven.

Takže je to šul nul.

[Grunt]

Vážený pane, opravy programů, pokud se tomu někdo věnuje přicházejí zhruba tak často, spíše častěji, než opravy knihoven.

Můj update-manager sice říká něco jiné, ale budiž. Nemám přesné statistiky v ruce, takže jsem (zatím) potichu.

[Filip Jirsák]

Něco jiného je překompilovat jeden opravený program, a něco jiného je překompilovat desítky programů, které používají nějakou knihovnu. S tím prvním mají zkušenosti třeba uživatelé Gentoo, a to se o nich říká, že neustále jen kompilují. Nevím, co pak musíte dělat vy, když toho kompilování máte ještě daleko víc.

[Jardík]

Jenže těžko máte 50 webových prohlížečů, 30 "univerzálních" komprimačních programů, 20 mailových klientů, 50 přehrávačů videa a 30 přehrávačů hudby... normální člověk má od každého typu programu jeden. Teda až na linux, tam jich potřebujete 5, protože žádný neumí nic pořádně.

[Filip Jirsák]

Tady se ale nebavíme o aplikacích, ale o knihovnách. Takovou knihovnu na zobrazení JPEG obrázků bude používat webový prohlížeč, e-mailový klient, přehrávač hudby, přehrávač videa, správce souborů, kancelářský balík, prohlížeč dokumentace a mnoho dalších programů. Další knihovny může používat ještě víc programů. A tyhle všechny programy budete překompilovávat při změně v jedné knihovně.

[Jardík]

Ale ve Windows ta knihovna je součástí systému, takže není třeba, aby si ji program tahal ...

[Michal Kubeček]

To, že je knihovna "součástí systému", na věci něco mění?

[Jardík]

Ano, program si ji nemusí tahat a zaktualizuje ji Windows Update. Když si nainstalujete program, tak ty mají většinou pouze knihovny na to, co systém neumí a většinou si žádné programy netahají ty samé knihovny, protože jsou k něčemu jinému. A pokud náhodou tam je u programu nějaká knihovna typu MSVC++ runtime, tak je to chyba vývojáře aplikace, msi instalátory "umí" závislosti (ve smyslu, že vám řeknou nainstaluj knihovnu, když ji nemáš, nebo ji nainstalujou, když je součástí "balíčku"). Jenže to by se vývojáři museli naučit vytvářet msi instalátory a nepoužívat 3rd party instalátory.

[Michal Kubeček]

Takže když je knihovna "součást systému", tak je správné linkovat ji dynamicky, zatímco když "není součástí systému", tak je všechno jinak a má se linkovat staticky? Pozoruhodné… A které knihovny jsou vlastně v Linuxu "součástí systému"? Žádná? Jenom glibc (a související)? Jen ty v /lib{,64}? Všechny, které jsou v distribučních balíčcích?

[Jardík]

Právě že je v případě linuxu je těžké říct, co je součástí systému, každý si to pak interpretuje po svém a pak např. 5 programů závisí pokaždné na jiné knihovně dělající to samé a máme přeplácaný systém. V případě Windows vývojář ví, co je součástí systému a může to použít. Pokud to nedělá a používá jiné knihovny, vytváří akorát bordel a je buď neznalý, nebo prostě to musí mít za každou cenu jinak (aneb proč by měl používat port GTK xml knihovnu microsoftu, když si může přivést vlastní, proč by měl používat windowsí funkce na kreslení fontů, když si můžou přitáhnout freetype a fontconfig ...).

Takže když je knihovna "součást systému", tak je správné linkovat ji dynamicky, zatímco když "není součástí systému", tak je všechno jinak a má se linkovat staticky?

Proč? Radši no comment a nechám toho, nebo se budeme bavit celý den o kravinách, na kterých se stejně nic nezmění.

[Grunt]

Právě že je v případě linuxu je těžké říct, co je součástí systému, každý si to pak interpretuje po svém a pak např. 5 programů závisí pokaždné na jiné knihovně dělající to samé a máme přeplácaný systém. V případě Windows vývojář ví, co je součástí systému a může to použít. Pokud to nedělá a používá jiné knihovny, vytváří akorát bordel a je buď neznalý, nebo prostě to musí mít za každou cenu jinak (aneb proč by měl používat port GTK xml knihovnu microsoftu, když si může přivést vlastní, proč by měl používat windowsí funkce na kreslení fontů, když si můžou přitáhnout freetype a fontconfig ...).

Jasně. Což je asi také důvod, proč je každý s Windows na Embedded systémech tak spokojený.

[Filip Jirsák]

V případě Windows vývojář ví, co je součástí systému a může to použít.

A co je součástí systému Windows? API Windows 95? Nebo Windows XP? Nebo Windows 7? A co takové .NET nebo MSI, to je také součástí systému?

[default]

Tak Photoshop to asi nebude, že.

[Grunt]

Tady je také knihovna součástí systému. Teda aspoň dle mého. Viz naše hádka s pavlixem o GNU, ne-GNU. Jen s tím rozdílem, že tady je to až do posledního bitu modularizovatelné. (v mém případě obří plus)

[Filip Jirsák]

Jistě, ve Windows je všechno součástí systému, takže instalovat tam nějaké další programy je vlastně zbytečné. A pokud něco prohlásíme za „součást systému“, tak se na to žádné ze zmíněných problémů nevztahují, v součástech systému nejsou chyby, neaktualizují se, neverzují se…

[Jardík]

O součásti systému se stará Windows Update, ty manuálně překompilovávat nemusíte ...

[Filip Jirsák]

Byly tady uváděny následující námitky proti dynamickým knihovnám: nová verze knihovny může zavléct chybu, program závisí na chybě v knihovně a s opravenou verzí nebude fungovat, program závisí na chybě v knihovně a vynucuje si tedy použití konkrétní verze knihovny. Jak se tyhle problémy vyřeší tím, že knihovny nazvete systémové a o jejich aktualizaci se stará nástroj, který nazvete Windows Update? Podle mne nijak a pořád jsou to knihovny jako kterékoli jiné.

[Grunt]

Jenže těžko máte 50 webových prohlížečů

Je jich jen o pár víc než ve standardních Widlích. No bóže. Já to mám rád, protože mám na výběr (každý je dobrý na něco jiného) v každé situaci a většina už má nějakou tu improvizaci v defaultu nainstalovanou.

30 "univerzálních" komprimačních programů

Každý používá jiný algoritmus, která má své plusy a mínusy. Každý si může udělat analýzu, který se hodí při jaké situaci a pak si podle situace vybrat a zefektivnit tak kompresi. Znovu vítám. Kdybych měl jenom jeden, autoritou přikázaný zip, tak ano, asi bych to otevřel vždy když mi někdo něco pošle, ale také bych za to asi vraždil.

20 mailových klientů, 50 přehrávačů videa a 30 přehrávačů hudby

A nepleteš si programy s knihovnama?

normální člověk má od každého typu programu jeden

Nechci do toho kecat, ale já i mám i ve Widlích od různých typů dva i více programů abych si efektivně mohl vybrat podle nastalé situace. Když jsou holt normální člověci lamy, tak co s tím? Mám se kvůli nim snad omezovat?

[Jardík]

Tím "univerzálních" jsem myslel program typu "já umím vytvářet 7z, rar, zip, tar, gz, bz2, xz, ...". A takový program se snadno zaktualizuje. Já radši jeden program, co umí víc "formátů", než 20 různých komprimačních programů.

A nepleteš si programy s knihovnama?

Ne.

Nechci do toho kecat, ale já i mám i ve Widlích od různých typů dva i více programů abych si efektivně mohl vybrat podle nastalé situace. Když jsou holt normální člověci lamy, tak co s tím? Mám se kvůli nim snad omezovat?

Dělej si, co chceš, já mám např. Windows Media Player na filmy i hudbu a nepotřebuji kvůli tomu instalovat VLC nebo cokoli jiného, protože to všechno WMP umí (filmy enkódovat nepotřebuju). Na web mám Chromium a nepotřebuji ještě firefox či IE, ke kreslení mi stačí Paint.NET a nepotřebuji ještě GIMP, malování, kritu a jánevímco. Fakt nevím, k jaké činnosti bych měl 2 aplikace.

[Grunt]

já umím vytvářet 7z, rar, zip, tar, gz, bz2, xz, ...

A? Na tom je něco blbě? To je jako vztekat se, že existuje aplay, madplay, mpg321, flac321, ogg321,… když tu máme mplayer. Vždyť tě nikdo nenutí používat ani instalovat referenční implementace a rozhodně to není, že by jsme měli 30 přehrávačů hudby a 50 komprimačních programů.

Na web mám Chromium a nepotřebuji ještě firefox či IE

Sám používám WebKit v podobě Epiphany a vím, že rozhodně to neumí vše a občas ten Firefox prostě potřeba je. Někdo holt používá víc aplikací k tomu stejnému a někdo se rozčiluje, že ten jeho neumí úplně všechno.

[Jardík]

Chromium mi zobrazí snad všechno. A když ne, tak si řeknu "no jo, tu webovku dělalo nějaký prase" a jdu od ní pryč. Abych kvůli tomu instaloval a spouštěl jiný prohlížeč? Za nic.

[Grunt]

no jo, tu webovku dělalo nějaký prase

LOL. Radši konec.

[Grunt]

Na Linuxu to jde též, ale není to jeho přirozené chování a obecně se agituje, že je to špatný nápad.

A také je. Všiml jsem si u Windowsích aplikací je to většinou jen pár knihoven a to je docela v pohodě, ale v případě svobodného softwaru jsou to někdy desítky až stovky knihoven což může být někdy docela šílené všechno pomixované s binárkama v jednom adresáři.

[Miloslav Ponkrác]

Já hlasuji pro Windowsí řešení.

V zásadě už jsem viděl mnoho nápadů a Windows to řeší asi nejlépe.

Linux se snaží předstírat, že programy neexistují, že každá aplikace má být jedna binárka a vše v jednom adresáři.

Novel Netware (nebo jak se to jmenovalo) zase přidal API každé sdílené knihovny do globálního prostoru názvů.

Když spravuji Windows, je to přehlednější, a řekl bych mnohem snadněji udržovatelnější, pokud si sázíte programy do vlastních adresářů.

V Linuxu je to jako v programu s miliardou globálních proměnných kdy nevíte co jí používá a kde jsou jaké vazby. Někde něco globálně změníte a vlastně si vůbec nemůžete být jist jaké všechny dopady to bude mít na zbytek systému, pokud je závislostí hodně.

Linuxový přístup je príma v případě, že držíte maličký systém – třeba v routeru, NASu, dedikovaném serveru. Tam je systém tak maličký, že všechny závislosti udržíte v hlavě a máte přehled.

Ostatně unix vnikl jako maličký, jeho kernel měl pár desítek tisíc řádků. Nikdo netušil do jak velkých rozměrů se to rozroste.

Mám pocit, že i Macu není přístup Linuxu ála globální těžko řiditelný systém baziliónu globálních vazeb všechno souvisí se vším a nikdo už pořádně nad tím nemá přehled použit. Ale Mac moc neznám, jen co se ke mně doslechlo.

[Grunt]

V zásadě už jsem viděl mnoho nápadů a Windows to řeší asi nejlépe.

Doporučuju nainstalovat MSYS nebo Cygwin. A nebo jakoukoliv standardní aplikaci z GNU. Windowsí řešení je nejlepší…pro Windows. Ale v případě portování svobodných aplikací začíná teprve to pravé šílenství.

Linux se snaží předstírat, že programy neexistují, že každá aplikace má být jedna binárka a vše v jednom adresáři.

Novel Netware (nebo jak se to jmenovalo) zase přidal API každé sdílené knihovny do globálního prostoru názvů.

Když spravuji Windows, je to přehlednější, a řekl bych mnohem snadněji udržovatelnější, pokud si sázíte programy do vlastních adresářů.

V Linuxu je to jako v programu s miliardou globálních proměnných kdy nevíte co jí používá a kde jsou jaké vazby. Někde něco globálně změníte a vlastně si vůbec nemůžete být jist jaké všechny dopady to bude mít na zbytek systému, pokud je závislostí hodně.

Linuxový přístup je príma v případě, že držíte maličký systém – třeba v routeru, NASu, dedikovaném serveru. Tam je systém tak maličký, že všechny závislosti udržíte v hlavě a máte přehled.

Ostatně unix vnikl jako maličký, jeho kernel měl pár desítek tisíc řádků. Nikdo netušil do jak velkých rozměrů se to rozroste.

Mám pocit, že i Macu není přístup Linuxu ála globální těžko řiditelný systém baziliónu globálních vazeb všechno souvisí se vším a nikdo už pořádně nad tím nemá přehled použit. Ale Mac moc neznám, jen co se ke mně doslechlo.

A o čem je to vlastně vůbec řeč?

[Miloslav Ponkrác]

Výborně, dokonalý argument. Řešení Linuxu je prostě nejlepší … o čem je to vlastně řeč?

Člověče, Vy jste v argumentační nouzi! Jinak řečeno, víte, že Váš názor nemáte čím obhájit.

Cygwin mi do Windows nesmí. Pokud něco napichuje NativeAPI Windows a nedokumentovaná (a tedy ani nezaručená) rozhraní Windows jako cygwin, jde to z mého počítače pryč a nikdy to tam nebude.

Já jsem plně spokojen s nativními programy pro Windows. Překompiloval jsem si MS Visual Studiem potřebné unix utility a jsem velmi spokojen. Mám nativně i bash. Samozřejmě staticky zkompilovaný.

[Grunt]

Výborně, dokonalý argument. Řešení Linuxu je prostě nejlepší … o čem je to vlastně řeč?

Co? To zas tvrdím kde? Bych si měl asi koupit brýle. A nebo bych to měl být opravdu já? Já jen tvrdím, že kombinovat knihovny a binárky v jednom adresáři je výhodné. Ale jen v případě, že je jich pár a že program nestojí na desítkách knihoven jako je tomu ve valné většině svobodných případů. Stejnětak není moc výhodné, když si třeba každá aplikace sebou táhne (a nebo má možnost si táhnout) svoji libgtk (Se pak moc dobře skinuje).

[Jardík]

Msys i cygwin jsou 32bit šmejďárny, co na 64bit Windows špatně fungují, protože jsou chybně napsané. Navíc předpokládají sizeof(long)=sizeof(void*) a proto nelze jednoduše vytvořit 64bit verze.

[Grunt]

, zas ta Jardík's ultimate answer? Sem se nebavil o tom jestli je to nebo není to šmejd, ale že se to tím Unix style prostě řeší jinak, což hned nemusí znamenat, že je to šmejd.

[Jardík]

Ale on to šmejd je, protože to závisí na nedokumentovaných součástech WinAPI, které nejsou součástí "public API" a pak to napůl nefunguje při nějaké změně.

[Grunt]

No dobře, tak jsou to oba šmejdy a hotovo. Co to na věci mění?

[Matlák]

Když spravuji Windows, je to přehlednější, a řekl bych mnohem snadněji udržovatelnější, pokud si sázíte programy do vlastních adresářů.

Já to takhle na linuxu dělám, a přehledné to je. Také mám hodně aplikací staticky slinkovaných. Má to právě tu výhodu, že kteroukoli aplikaci prostě jako jeden kus zataruju a pustím na jiném stroji... vlastně mi stačí adresáře dva - s aplikací a s konfigurací. Pořád je ale Mac myslím o krok dále - komplet celá aplikace je prostě obraz fs který je v jednom .dmg a hotovo. Kam se hrabou windows

[Jendа]

Na Macu je co vím trochu problém s aktualizací, pokud systém používá více než jeden uživatel.

[Matlák]

Obecně je s aktualizací v takovém případě problém. Já mám na linuxu statické jen ty programy ("aplikace") které jsou poměrně rozsáhlé, složité na ovládání a samy o sobě tvoří nástroj (na video, grafiku, zvuk apod..) na jehož ovládání a výhody (a také nedostatky..) si člověk zvykne.

Jejich počet je maximálně v desítkách, a aktualizuju je jen když mám pocit že mi nová verze něco opravdu nabídne. Oproti tomu u většiny unixových utilit je centrální systém požehnáním..

[Jardík]

Na MacOS je problém s aktualizací i v případě jednoho uživatele, pokud "neinstaluje" do /Applications, aktualizátor tu aplikaci pak nevidí. Na MacOS je ale problém i se spouštěním aplikací, např. takový photoshop se ani nespustí, pokud máte case-sensitive filesystém...

[Daniel Kvasnička ml.]

Na MacOS je problém s aktualizací i v případě jednoho uživatele, pokud "neinstaluje" do /Applications, aktualizátor tu aplikaci pak nevidí. Na MacOS je ale problém i se spouštěním aplikací, např. takový photoshop se ani nespustí, pokud máte case-sensitive filesystém...

...coz samozrejme neni problem Apple, ale lemplovskeho Adobe. Jejich aplikace jsou uz dlouho peknou ukazkou nedotazenosti, pokud jde o jejich OS X verze. Vsak proc by se snazili, kdyz maji v oblasti profi grafiky de fakto monopol?

[Jardík]

ale lemplovskeho Adobe

Na tom se shodneme

[dfbhdf]

Skutečně? A proč mi každý druhý program nacpe bordel v podobě hromady cizích knihoven do C:\Windows\System32? (nebo jak se ten adresář vlastne jmenuje)

[Jardík]

To sou keci, to dělaly špatně napsané aplikace v dobách Windows 95. A pokud si to dovolí i nějaká dnešní aplikace, tak je to chyba tvůrce programu, protože je prase. Knihovnu si může nacpat do svého adresáře. BTW windows podporuje i verzování knihoven, ale to by se s tím vývojáři museli učit zacházet, takže to neprovozují (resp. provozuje to tak možná akorát Microsoft).

[Matlák]

Linuxový přístup je príma v případě, že držíte maličký systém – třeba v routeru, NASu, dedikovaném serveru. Tam je systém tak maličký, že všechny závislosti udržíte v hlavě a máte přehled.

No a windowsí přístup je na tom podobně. Asi těžko bych dokázal spravovat "windowsím způsobem" několik tisíc aplikací, z nichž každá by byla vlastně jen jednoduchou utilitou, která by musela vědět o tom kde jsou ostatní. A v tomhle je právě přístup přes registry a přeplněné adresáře typu "system32" poněkud podivný a často vede k zpomalování a nekonzistencím

[Jendа]

Když spravuji Windows, je to přehlednější, a řekl bych mnohem snadněji udržovatelnější, pokud si sázíte programy do vlastních adresářů.

Dobře. A jak zní ten jeden příkaz, kterým se všechny aplikace v systému zaktualizují? Respektive jak byste takto udržoval aktuálních 50 stanic s 600 uživateli?

Na Windows je to sázení do vlastních adresářů stejně jenom takové polovičaté, protože spousta aplikací používá centrální registry a System32\.

Linux se snaží předstírat, že programy neexistují, že každá aplikace má být jedna binárka a vše v jednom adresáři.

A víte, že je mi to celkem jedno? Nepamatuji si, kdy jsem naposledy potřeboval ručně sáhnout do /usr/bin či /usr/lib. A to ani na Ubuntu, ani na Archu, ani na Debianu. Pár vlastních věcí mám v /opt a tam je to skutečně jeden program - jeden adresář.

[Radek Miček]

Respektive jak byste takto udržoval aktuálních 50 stanic s 600 uživateli?

Na to se používá například Microsoft System Center Configuration Manager.

[Jardík]

Na Windows je to sázení do vlastních adresářů stejně jenom takové polovičaté, protože spousta aplikací používá centrální registry a System32\.

Keci. Viz. někde výše. Registry ... každý slušně napsaný program si používá svůj klíč a nedělá bordel. Prasácké programy si slušný člověk neinstaluje.

[bender]

jardo ty si s prominutím kokot. prasáckých programů je mraky, je vidět že jsi zaprděný namachrovaný studentík, který nepracuje. jako sys admin vím, že většina korporátních programů je víc než prasácky naprogramovaná a vyhnout se jim nelze a autor třeba i velká megakorporace sere na nějaké tvé názory. a v linuxu je taky spousta prasáren, ale už ne tolik. sundej ty růžové brýle.

[pht]

Tak to zas pr. Např. já pracuju už dlouho a nic neprasím, a znám spoustu lidí kteří to taky tak dělají. Dokonce se o tom píší knihy. A dokonce se píše i o tom, jak ty vaše mega-korporace z roka na rok spadly na držku právě kvůli problémům s pořádkem v kódu. A řekl bych že např. microsoft bude jedna z nich.

[Chytrex]

žel má bender naprostou pravdu.. když vidím ty bastly, které pro produkci musíme používat, tak se opravdu divím, že tahle firma ještě vydělává.. Pořád něco nefunguje, v "lepších chvílích" i dvě stěžejní věci naráz.. Upgrade na novou verzi nic nevyřeší, ale zato rozbije další 2 věci.. A moc nevěřím, že to bude v jiných firmách lepší, když to takhle vypadá v jedné "malé" nadnárodní firmičce..

[pht]

A moc nevěřím, že to bude v jiných firmách lepší, když to takhle vypadá v jedné "malé" nadnárodní firmičce..

Ale je. To že tam máte bordel neznamená že ho mají všichni.

[danaketh]

Řešení ve Windows je strašný. Hlavně proto, že tam má každej svůj instalátor a pravá ruka neví, co dělá levá. Ve finále to dopadá tak, že je systém plný věcí, které třeba už dávno nic nepoužívá - jen neexistuje způsob jak se toho zbavit.

Kdyby si každá aplikace držela co potřebuje u sebe, tak je to skoro ok ale ono něco je tu, něco tamhle a při odinstalování tam toho polovina zůstane - a děje se to i na Windows 7.

V Debianu spustím aptitude a nechám to vyčistit ze systému všechno, co není k užitku. Nic mi nikde nezůstane smrdět. Ve Windows je něco u aplikace, něco v system32/, něco přímo ve windows/, něco v ~/ a to nemluvím o registrech :)

[danaketh]

Kromě toho aktualizace je na oběšení - vývojáři oznámí, že v knihovně XY je bezpečnostní díra, která byla opravena. Fajn, mám Linux, v něm správce balíčků a všechno je slinkované dynamicky. Spustím (v mém případě) "aptitude full-upgrade" a opravená verze se mi stáhne a nainstaluje a bug je fuč.

A teď mám Windows. Pokud jde o něco od MS, budu doufat, že se někdy dočkám updatu (pokud to vůbec budou řešit) a ten nějak nepodělá celý systém (viděl jsem několikrát). Když jde o nějakou rozšířenou věc kterou ale nemá v režii MS, musím si stáhnout instalátor nebo v horším případě danou knihovnu samotnou. Pak mohu jen doufat, že najdu všechny aplikace a všechna místa, která knihovnu používají.

Nemluvě o faktu, že většina chyb ve Windows se neřeší (a není to jen přímo v OS - týká se to i non-MS aplikací) zrovna pružně a rychle, pokud se tedy vůbec řešej.

[Jardík]

Určitě najdeš 50 programů používajících např. OpenSSL ... jestli najdeš jeden, tak seš dobrý a zároveň blbý, používat extra SSL knihovnu, když to umí systém samotný, to je něco...

[Grunt]

Tak se to prostě řeší jinak, no. Se nepatlou požadavky skrze nějaké systémová API centrálnímu bohu počítače, ale každý se holt ptá svých součástí (a takové OpenSSL se klidně dá považovat za systémovou knihovnu). V GNU/Linuxu je i dynamický loader jako knihovna a dokonce i systémové hacky se řeší přes knihovny. Je to snad špatně?

[kotyz]

kdyz rek jardik ze to je spatne, tak to je spatne!

[Jardík]

Ano, já bych taky OpenSSL považoval za systémovou, horší je, že jiná aplikace chce třeba zase GNUTls a pak máte 2 knihovny na to samé - o to díky tomu, že to není "součást systému", tak si každý vývojář vybere jinou (na což má právo, ale pak chudák uživatel, co nemá internet a stahuje každý den v internetové kavárně jinou knihovnu (nepravděpodobné, ale))

[Grunt]

Já nevím, ale neuniklo ti náhodou, že OpenSSL a GnuTLS jsou naprosto dvě odlišné knihovny?

[Jardík]

Fakt? Obě umí SSL a nedávno mi nějaký port ve freebsd dával na výběr OpenSSL nebo GnuTLS, co to ale bylo zač si nepamatuju, FreeBSD jsem smazal, protože nemá alternativu k inotify a kqueue mi brání odmountovat filesystém při sledování změn na souboru.

[petr_p]

A už jste ještě neslyšel o NSS, PolarSSL a spoustě dalších, které dělají „to samé“ :)

Nicméně mezi OpenSSL a GnutTLS jsou rozdíly. Pro někoho to může být licence, pro někoho (ne)podpora PGP v TLS, pro někoho výkon, pro někoho kompatibilita, pro někoho certifikace FIPS…

[default]

Nepravděpodobné? Co třeba takový GPRS?

[Jardík]

S tím jsem si taky kdysi užíval, naštěstí tu nakonec to ADSL zavedli

[petr_p]

Například 602 XML Filler :)

[Jardík]

To je stějně nějaká 32bit šmejďárna, to na dnešních počítačích nemá co dělat

[kotyz]

kdyz mas povinnost pouzivat ISDS tak se ty smejdarne nevyhnes. a na linuxu je to navic 32bit win smejdarna zabalena s wine ktera nekdy ani nefunguje a kdyz uz funguje tak ne poradne ...

[Jardík]

A stát nedává zdarma PC s 32bit Windows k tomu, abys to mohl používat? Ať se jdou vycpat. Ale je to chyba občanů, že neprotestují, nežalují stát, nedaj to k soudu či tak něco. Přece mi nebudou nakazovat, co mám používat za systém. Co kdybych měl jen Windows Server 2008 R2 (bez podpory 32bit binárek), nebo jen 64bit linuxový kernel? To mi jako budou poroučet kupovat si starý počítač se zastaralými systémy? Nebo mě budou nutit chodit jánevímkam? Se radši nechám zavřít, dostanu zadarmo napít, najíst, sem tam nějaký ten sex do análu a nebudu muset řešit datové schránky

[kotyz]

LOL Lidi protestujou, ale asi malo nebo je tak snadny ty davy protestujicich ignorovat. Stat ti nenarizuje mit windows ani 602xml, akorat ti narizuje pouzivat ten system ISDS a ze to bez windows a 602xml zatim (jo, maka se na naky free a open implementaci, ale to asi jeste dlouho nebude hotovy) nejde nevi, neresi a je jim to jedno. Zaridit si to musis sam a kdyz to neudelas je to jenom tvuj problem. Neznalost zakona neomlouva a ta desetidenni fikce doruceni plati furt ...

Ono pro nektery byl problem to pouzivat ikdyz meli widle a 602xml, protoze nedokazali na klavesnici napsat trebas # (jednomu zemedelci sem ji zakladal, asi 2 mesice po tom co to uz mel povinne pouzivat, mel tam uz nejaky zpravy ktery byly "precteny" ikdyz se tam jeste nikdo nikdy neprihlasil a sam by to asi nikdy nezvlad) a heslo si museli psat na listecek a ten strcit do supliku a pri kazdym prihlaseni ho vytahovat. Proti tomu se mozna bourili vic nez kvuli tomu ze musi mit windows, ktery uz stejne vetsinou meli, ale to ze si musi pamatovat heslo slozitejsi nez pepik1 to je zvedalo ze zidle ...

Proste takovej bordel a saskarna se jen tak nevidi Jeste ze nemam zivnost ani eserocko abych tu saskarnu musel taky pouzivat (muze bejt jen otazka casu nez to bude povinny pro vsechny).

[rem]

Já hlasuji pro Windowsí řešení.

taky bych rád hlasoval PRO.

[thingie]

Vždyť si to můžete nalinkovat jak chcete. Krom toho nechápu, proč by někdo studoval co všechno je někde v /usr/bin, pokud teda náhodou není doplňovač z bashe (což by teda měl dost nízké ambice, ale tak Ponkrác). Říct si rpm -q balicek -f je úplně to samý jako mít to všechno rozházený po všech čertech. Pokud po tom tak toužíte, napište si nad fuse udělátor, co vám tohle promítne do fs. Nebo i jenom blbej skript kde bude pár mkdir a ln. Velká věc. (K ničemu.)

[DWD]

Vždyť si to můžete nalinkovat jak chcete. Krom toho nechápu, proč by někdo studoval co všechno je někde v /usr/bin, pokud teda náhodou není doplňovač z bashe (což by teda měl dost nízké ambice, ale tak Ponkrác). Říct si rpm -q balicek -f je úplně to samý jako mít to všechno rozházený po všech čertech. Pokud po tom tak toužíte, napište si nad fuse udělátor, co vám tohle promítne do fs. Nebo i jenom blbej skript kde bude pár mkdir a ln. Velká věc. (K ničemu.)

O tom by mi zajímalo více podrobností.

[pht]

V Linuxu je to jako v programu s miliardou globálních proměnných kdy nevíte co jí používá a kde jsou jaké vazby. Někde něco globálně změníte a vlastně si vůbec nemůžete být jist jaké všechny dopady to bude mít na zbytek systému, pokud je závislostí hodně.

Tohle je spíš případ Windows. Změňte něco v adresáři system32 a řekněte mi, jaké to bude mít všechny dopady? V linuxu se můžete aspoň podívat, které programy daný soubor používají.

Ale ne, chcete snad říct že "do systému se nesmí hrabat"?

Tam je systém tak maličký, že všechny závislosti udržíte v hlavě a máte přehled.

Nemusíte nic držet v hlavě, na to máte ten stroj. V hlavě si pak můžete udělat místo na něco, co ten stroj zatím neumí.

Linuxu ála globální těžko řiditelný systém baziliónu globálních vazeb všechno souvisí se vším a nikdo už pořádně nad tím nemá přehled

Omílání omylu. Tohle není pravda. Díky explicitnímu sledování závislostí máte naopak naprosto přesný přehled nad vším. A dokonce se tam nesmí stát, aby v závislostech vznikl cyklus, takže nemůže "všechno souviset se vším".

[default]

Všiml jsem si u Windowsích aplikací je to většinou jen pár knihoven a to je docela v pohodě, ale v případě svobodného softwaru jsou to někdy desítky až stovky knihoven

Protože ve Windows či OS X je součástí systému přesně to, na co je v Linuxu dva tisíce knihoven.

Problém je v míchání programů a systému. GNU/Linux prostě jen vytahuje systémové věci na světlo boží. Takže i normální uživatel má šanci si všimnout grafických knihoven, Pythonů, Perlů…

Není na tom nic špatného. Akorát, když se běžní uživatelé začnou ptát, nikdo jim nedokáže uspokojivě odpovědět (ano, odpovědi typu svoboda výběru ponechme stranou).

[Grunt]

Protože ve Windows či OS X je součástí systému přesně to, na co je v Linuxu dva tisíce knihoven.

Ono je to totiž rozdílným způsobem vývoje. Nač vyvíjet něco co už je vyvinuté? Nač to krást, staticky linkovat, obfuskovat a schovávat? Většina programů je jen slepencem funkcí, které nabízejí různé knihovny + něco málo jako přídavek. Pak si holt sebou program táhne různé knihovny jako závislosti. Já na tom též nevidím nic špatného. Spíš naopak.

Akorát, když se běžní uživatelé začnou ptát, nikdo jim nedokáže uspokojivě odpovědět

Na co se začnou ptát?

[Matlák]

Na co se začnou ptát?

Například na to proč nemůžou vzít ten supr střihový nebo zvukový program a jako kazetu nebo cd jej přenést do jiného stroje.. proč programy nejsou krabičky co je možné přesouvat.. například

[Mrkva]

To nemůžu ani u většiny programů pro Windows :) Například.

[default]

Ale můžeš. U většiny stačí zazipovat ten adresář v Prdel Files/ a hotovo. Druhej si akorát ten program znova nakonfiguruje, protože registry.

[Grunt]

Uspokojivá odpoveď(?):

http://disk.jabbim.cz/grunt@jabber.cz/lama.png

---

Změnil jsem vložený obrázek na odkaz. Filip Jirsák

[Matlák]

zcela uspokojivá

prostě pro BFU jsou soubory něco jako kamínky, které může přesypávat, a programy černé krabičky s hezkými tlačítky uvnitř. To žádný ajťák nezmění. Proto má většina BFU ráda Mac, kde to opravdu jde "přetahovat" a tím instalovat i mazat programy... kde je všechno "na dosah ruky" proto taky ten boom s jinak poněkud nepraktickými dotykovými GUI. No a další důsledek je že většina BFU nemá ráda terminály a vůbec textové rozhraní

[Grunt]

Změnil jsem vložený obrázek na odkaz. Filip Jirsák

To už spíš zcenzurovat, protože s tím klikáním to nemá tu správnou chuť.

[default]

Ono je to totiž rozdílným způsobem vývoje.

A rozdílným způsobem distribuce.

Nač to krást

Samoobsluhy Tvůrčích Monopolů™ sem prosím netahej.

Nač to krást, staticky linkovat, obfuskovat a schovávat?

Citation Needed.

Na co se začnou ptát?

Například: "Proč mám po instalaci holého systému pět tisíc balíčků? Já si nainstaloval jen systém!?" Uživatel může být prostě zmatený.

[Marek Bernát]

Na čo sú pod kapotou všetky tie kolieska? Ja som si kúpil len jedno auto.

[default]

Já se srovnávání s auty neúčastním. Nemám ani auto, ani řidičák. Ale když jsem v autě jel, nikdy jsem si nevšimnul, že by byl vnitřek motoru či převodovky posádce nějak prezentován.

[Marek Bernát]

Mno, veď to nemusí byť ani v tom OS. Až keď sa niečo poserie, tak sa musíš pozrieť pod kapotu Ale máš pravdu, ja analógie tiež nemám rád, obvykle viac zavádzajú, než ozrejmujú.

[Jendа]

Já když jsem jel v Ubuntu, tak jsem si také nevšimnul, že by byl vnitřek motoru či převodovky posádce nějak prezentován.

[danaketh]

Na pravé straně můžete vidět zátiší dynamicky linkovaných balíčků, na straně pravé pak vesele poskakují balíčky linkované staticky.

[Michal Kubeček]

Ve slušné autoškole by vás s aspoň základním principem převodovky a spojky seznámit měli.

[default]

A jak to souvisí s tím, jestli ta střeva mají či nemají být vidět??? OMG!

[danaketh]

Tady taky :) Uživateli řeknu, že existuje balíčkovací systém, který za něj bude řešit instalaci programů a toho co potřebují. V autoškole nám taky říkali jenom "k čemu" to je, ne jak to funguje. To přece řidič nepotřebuje vědět - on bude autem jezdit, ne se v něm vrtat. A ten co se v něm bude chtít hrabat si to zjistí sám.

[Grunt]

Lidi, kteří by jen jezdili (a když se to posere, nech se starají jiní – k tomu já nejsem určen, já jsem určen k ježdění) fakt nesnáším. Dřív platili zlaté české ručičky a když se kamioňákovi rozbilo vozidlo někde v cizině, tak si ho sám dovedl s kladívkem opravit. Ach jo, kde jsou ty časy?

[Jendа]

Ale oni se pokoušejí počítač opravit svépomocí. A podle toho to pak vypadá - spamy, botnety, DDOS útoky… Možná ještě štěstí, že stejně nepřistupují třeba k brzdám - lepší dostat do schránky trochu viagry, než být na ulici rozmačkán nebrzdícím kamionem.

[danaketh]

Já "jen jezdím". Necpu se do práce automechanikovi, protože tomu nerozumím. Radši mu zavolám, když mi to nejede (navíc se v tom dneska ani moc vrtat nedá). On mi taky volá když má problém s PC a nehrabe se v tom sám... Proč? Protože tomu nerozumí a nepotřebuje rozumět - ví, že když bude problém, může se obrátit na mě.

Zlaté české ručičky platí dodnes ale jsou věci, které je prostě lepší nechat odborníkovi. Mě třeba hrozně baví s kamarádem opravovat motorky ale jsem mu platnej akorát na čištění dílů, protože si prostě nepamatuju co, kam a jak patří :)

Nejde o to "já jsem určen k ježdění" ale "radši se v tom nebudu vrtat když tomu nerozumím". Nejhorší je totiž člověk, co má pocit že tomu rozumí - po něm to totiž čast dohromady nedá ani kouzelník :)

[Grunt]

A rozdílným způsobem distribuce.

Který se jen přizpůsobuje jinému způsobu vývoje.

Samoobsluhy Tvůrčích Monopolů™ sem prosím netahej.

Čeho?

Citation Needed.

Jako k čemu? Že se krade, staticky linkuje aby se schovalo, schovává a obfuskuje? Já už to beru spíš jako axiom.

Například: "Proč mám po instalaci holého systému pět tisíc balíčků? Já si nainstaloval jen systém!?"

Protože normálně je to také tak, jen je to všechno pěkně úhledně poschovávané ve svých binárkách.

[multi]

ke stahoveni baliku - staci si vypsat vsechny zavislosti a stahnou si vse najednou, ale kdo nema dneska internet :-O ?

podle me hl. vyhoda je setreni pameti pri dynamickem linkovani - proc mit take stokrat nacteny ty same knihovny? Bohate me staci, kdyz kvuli nekterym programum musim mit nacteny knihovny i pro 32 bit programy, pak se akorad divim, ze me 64bit system zere tolik pameti, pritom za to muzou ty 32bit programy

[Jendа]

ke stahoveni baliku - staci si vypsat vsechny zavislosti a stahnou si vse najednou

Synaptic dokonce umí vyrobit seznam URL těch balíků, který pak stačí předhodit nějakému download manageru.

[Miloslav Ponkrác]

podle me hl. vyhoda je setreni pameti pri dynamickem linkovani - proc mit take stokrat nacteny ty same knihovny?

Zase jeden věřící, co si myslí, že dynamické knihovny šetří paměť.

Vážení pánové, každá knihovna a x86 kód potřebuje relokaci, tedy přepočítat při přesunu na jinou adresu. Tedy nahrajete-li stejnou dynamickou knihovnu do pěti programů, bude pravděpodobně v paměti ta knihovna 5×, tudíž k ušetření paměti nedochází. Protože v každém programu bude na jiné adrese, tudíž se kód knihovny nedá sdílet a bude muset být v paměti 5×.

Ve skutečnosti staticky slinkovaný program bude zabírat méně paměti ve většině případů.

Právě proto existuje standardizace. Systém, který standardizuje omezený počet systémových sdílených knihoven jako základní API systému si může dovolit předepsat systémovým knihovnám pevnou adresu, na kterou se adresa natáhne. Pak skutečně bude v paměti vždy jednou. Je třeba aby se vzájemně standardizoval seznam základních knihoven, domluvili se mezi sebou, rozepsali si adresy, kam budou nahrány a umísťovali je na pevné adresy. Tak je to třeba ve Windows.

Nicméně Linux brání strategii, že jakékoli standardy, či domluva je omezování svobody a fuj, takže s emůžete spolehnout, že dynamické knihovny v Linuxu opravdu ani náhodou paměť nešetří.

[dfbhdf]

...API systému si může dovolit předepsat systémovým knihovnám pevnou adresu, na kterou se adresa natáhne...

Sen každého útočníka

[Miloslav Ponkrác]

Musíte si vybrat. Buď pevná adresa .so a pak z toho vyplývající šetření pamětí. A nebo pohyblivé adresy .so, ale pak se žádné šetření pamětí nekoná.

Můj příspěvek byl hlavně o vyvracení obrovské lži, že dynamické knihovny snad obecně šetří paměť.

Přesto je schopno mnoho lidí lživě tvrdit, že dynamické knihovny šetří paměť. Tahle urban legend se koukám drží hodně pevně zakořeněná.

[dfbhdf]

Takže například vývojář glibc z RedHatu tomu nerozumí? Nebo snad lže?

viz bod 3

[oroborus]

Vážení pánové, každá knihovna a x86 kód potřebuje relokaci, tedy přepočítat při přesunu na jinou adresu. Tedy nahrajete-li stejnou dynamickou knihovnu do pěti programů, bude pravděpodobně v paměti ta knihovna 5×, tudíž k ušetření paměti nedochází. Protože v každém programu bude na jiné adrese, tudíž se kód knihovny nedá sdílet a bude muset být v paměti 5×.

IMHO:

Na toto sa samozrejme myslelo. Kniznica je vo fyzickej pamati nahrana iba raz. Vo virtualnom adresovom priestore kazdeho procesu ma vzdy inu adresu. Kniznica potrebuje realokaciu, ale to este neznamena, ze sa upravi jej cely binarny obraz pre kazdy proces, cim by sa znemoznilo zdielanie.

Ak ide o intrukcie skoku v ramci kniznice (instrukcia skoku v kode kniznice, ktora odkazuje na ine miesto v kniznici) s tymto nic robit netreba, lebo vsetky skoky su adresovo relativne, ako parameter je ulozeny iba offset o ktory sa skace.

Inac sa riesi, ked kod kniznice musi volat kod z inej kniznice. Uvediem to na priklade: kniznice libSDL pouziva knizincu libc, z nej chce volat funkciu malloc. Namiesto toho aby priamo volala funckiu malloc, ktora moze byt vzdy na intej adrese. zavola funkciu malloc@plt ktoru ma vo svojej sekcii .plt a stade sa vykonavanie programu preniesie na funkciu malloc v kniznici libc. Pri realokacii sa musi zmnenit iba plt tabulka

[Grunt]

Přesně tak. Knihovny se IMHO cpou do sdílené paměti, bůh ví jak se mapují, takže klidně nech v té paměti 5× jsou… teda když to nebude ve fyzické.

[tom]

Vážení pánové, každá knihovna a x86 kód potřebuje relokaci, tedy přepočítat při přesunu na jinou adresu. Tedy nahrajete-li stejnou dynamickou knihovnu do pěti programů, bude pravděpodobně v paměti ta knihovna 5×, tudíž k ušetření paměti nedochází. Protože v každém programu bude na jiné adrese, tudíž se kód knihovny nedá sdílet a bude muset být v paměti 5×.

Lžete, vizte http://cs.wikipedia.org/wiki/Position_Independent_Code

[Amarok]

V praxi bude pravda nekde mezi. Zalezi spis na tom, co ta knihovna obsahuje, jestli tridy, z nichz vetsina nema staticke metody apod., v tom pripade by se moc pameti neusetrilo.

[pht]

Protože v každém programu bude na jiné adrese, tudíž se kód knihovny nedá sdílet a bude muset být v paměti 5×.

Tohle je kravina, sdílí se paměť všech spustitelných objektů (statických i dynamických), takže jsou fyzicky v paměti maximálně* jednou a veškeré přemapování adres zajišťuje stránkovací jednotka.

* Jelikož jsou původně v souboru na disku, při spuštění se pouze stránka RAM namapuje na prostor na disku a do RAM se načte až když je opravdu potřeba.

Nicméně Linux brání strategii, že jakékoli standardy, či domluva je omezování svobody a fuj, takže s emůžete spolehnout, že dynamické knihovny v Linuxu opravdu ani náhodou paměť nešetří.

Doporučuju si přečíst aspoň něco okolo VMM v Linuxu. Linuxové jádro je opravdu hodně líné a nealokuje žádnou RAM dřív než je opravdu potřeba.

Například když si při alokaci objednáte 20 megabajtů nul, tak dostanete hromadu referencí na tentýž 4kb segment v paměti. Dokud ty nuly nezačnete přepisovat tak žádnou další paměť nevlastníte.

[muf]

Prehled duvodu proc staticky nelinkovat:

http://people.redhat.com/drepper/no_static_linking.html

[Miloslav Ponkrác]

Škoda, že jsou to jenom kecy.

Ohledně šetření paměti jsem napsal výše.

Nehledě, že druhý a třetí bod se vzájemně vylučují. Čím náhodněji na různé adresy budete knihovny nahrávát, tím spíše bude muset být knihovna v paměti několikrát, protože díky relokaci se nedá sdílet.

Třetí bod je lež úplně.

Stejně tak předpoklad, že nové verze .so budou vždy jen lepší a méně chybové, než starší je poněkud – no jak to říct – raději si odpustím komentář.

Myslím, že každému člověku delší dobu se pohybujícího v počítačích se stalo, že po upgradu přestalo něco jiného fungovat kvůli chybě v nové knihovně.

Škoda, že v linuxových materiálech je více dojmologie, než pravdy. I v tomto.

Co je pravda je, že LGPL dynamické linkování vyžaduje, ale to je umělý právní důvod.

[Mrkva]

Hmm, nechtěl byste jim do RedHatu napsat, že to dělají úplně špatně? :)

[Radek Miček]

Třeba ten první bod je pravda, jen pokud se nezmění ABI.

Nevýhoda dynamického linkování je nemožnost globální optimalizace a také to, že se načítá celá knihovna, i když je potřeba jen její určitá část.

[Ivan]

Tohle neni pravda. Viz "LAZY BINDINGS". Kazda knihovna ma vpameti minimalne dva segmenty. Prvni je RO a je sdileny, druhy slouzi pro relokace a je RW. Kazda funkci z knihovny prislusi tzn. loader z toho RW segmentu, pokud poprve z programu zavolate "printf" tak nejdrive skocite na ten "loader" ten namapuje kus kodu z disku, prepise loader(sam sebe) na call(nebo jmp ted nivim) a pak ten print zavola. Pri dalsim volani uz se jde naprimo.

Je to videt kdyz si prohlidnete /proc/self/smaps.

[Radek Miček]

S tím souhlasím. Ale stejně nakonec musíte načíst do fyzické paměti stránky s kódem knihovny, který obsahuje volané funkce. Takže, když voláte několik funkcí a každá je k vaší smůle v jiné stránce, musíte načíst všechny tyto stránky, i když by se ten kód co potřebujete vešel třeba jen do jedné stránky. (Samozřejmě, pokud tu knihovnu používá více programů, tak se paměť ušetří díky sdílení.)

[Martin Mareš]

Čím náhodněji na různé adresy budete knihovny nahrávát, tím spíše bude muset být knihovna v paměti několikrát, protože díky relokaci se nedá sdílet.

A jéje, pan kolega se opět rozhodl předvést, že o tom, jak věci doopravdy fungují, toho ví pomálu. Sdílené knihovny na Linuxu už nějaký ten pátek jsou position-independent, takže se relokace týkají jen mizivé části adres (povětšinou ukazatelů umístěných v datech).

Jednotlivé instance dynamické knihovny sdílejí naprostou většinu prostoru, instance statické knihovny nesdílejí naprosto nic.

[Grunt]

Ale ono to tak jak popisuje p. Ponkrác opravdu funguje. Jen u něčeho jiného. Asi mluví z vlastní zkušenosti.

[danaketh]

Kolik lidí v roce 2010 nemá internet? A kolik z nich používá Linux?

[DWD]

Zajímalo by mě, jak při tvorbě balíků, například RPM, ovlivním, jestli budou linkované staticky nebo dynamicky.

Jinak: Viděl jsem program Renoise (ten sice nepoužívám), a ten nemá žádné závislosti, ani není určené, pro jakou distribuci a verzi Linuxu se hodí.
renoise Pro instalaci programu stačí jenom nakopírovat soubor do vhodného adresáře a program je připravený k použití. Proto nevím, proč by to tak jednoduše nemohlo jít pro kterýkoliv program.

[chrono]

Zajímalo by mě, jak při tvorbě balíků, například RPM, ovlivním, jestli budou linkované staticky nebo dynamicky.

Len veľmi málo rpm balíkov ma .spec súbor vytvorený tak, aby sa dala vytvoriť aj staticky skompilovaná verzia, takže ak niečo také chceš, budeš si musieť upraviť kompletne celý systém (pretože by staticky musel byť skompilovaný kompletný systém a od klasickej distribúcie sa také niečo asi čakať nedá).

Síce môžeš použiť nejaké parametre pre kompilovanie a linkovanie, ktoré sa pokúsia vytvoriť statickú verziu, ale je veľmi pravdepodobné, že to fungovať nebude (a ako som už písal, musíš mať všetky potrebné knižnice skompilované kompletne staticky), takže bez úpravy .spec súbora to asi nepôjde (a niektoré knižnice/programy sa kompletne staticky ani vytvoriť nemusia dať).

[Matlák]

Samozřejmě že by to šlo pro každý program. Podobně to třeba dělá Skype, ale také různé hry a vůbec komerční software.

Na statických balících (binárkách) se mi líbí ta přehlednost, je to podobné jako na Macku - prostě soubor přetáhnu a spustím. Na druhou stranu občas program závisí na tolika věcech, že opravdu zabere zbytečně obrovské množství místa (velikost nainstalovaných programů pro Mac či Windows toto potvrzuje).

Je fakt že repozitáře mají spoustu nevýhod, právě kvůli tomu že systém musí být jako celek konzistentní, a instalace programu pro jinou distribuci, používající jiné knihovny je problém.. každopádně například vnášejí do systému značnou bezpečnost a čistotu.

Na druhou stranu pro vývojáře je to spíš otrava, zvlášť kvůli tomu že se knihovny pořád mění a na nějaké standardizované API se často není možné spolehnout. Pro vývojáře je mnohem snazší slinkovat výsledný program staticky než tvořit přinejmenším desítky balíků pro různá distra.. btw imho je to důvod proč je o tolik víc volně šiřitelných programů v binárkách pro windows..

[Grunt]

prostě soubor přetáhnu a spustím

No, u některých otevřených programů by to přetáhnu a spustím nemuselo být zas tak úplně košer, protože některé krom /bin, /include a /lib složek mají i nějaké /share knihovny kde si nesou soubory nezbytné ke svým programům a ty se většinou nastavují pomocí parametru --prefix při kompilaci. Nehledě na to, že pokud jde o dynamicky slinkovanou verzi, tak neznám žádnou takovou, která by měla cestu ../lib/*.

No jinak ale nechápu o čem se to bavíme. GNU není čistě binární operační systém a u něj by něco takového stejně nemělo začínat stáhnu/přetáhnu a spustím, ale stáhnu/přetáhnu, zkompiluju a spustím, leč jsou téměř ke všemu dostupné zdrojáky.

Pro vývojáře je mnohem snazší slinkovat výsledný program staticky než tvořit přinejmenším desítky balíků pro různá distra.. btw imho je to důvod proč je o tolik víc volně šiřitelných programů v binárkách pro windows..

Jo, jenže následná údržba něčeho takového je také potom docela prdel. Což je také možná důvod, proč něco takového na Windowech téměř neexistuje.

[Matlák]

No, u některých otevřených programů by to "přetáhnu a spustím" nemuselo být zas tak úplně košer..

No možná proto mají programy na Macku podobu obrazů filesystémů.. Je to svým způsobem elegantní, především z hlediska výrobce softwaru.

Jo, jenže následná údržba něčeho takového je také potom docela prdel. Což je také možná důvod, proč něco takového na Windowech téměř neexistuje.

To je pravda, zase na woknech (a i na Macu ostatně..) je spousta komerčního softwaru. To je ten kámen úrazu. Faktem je že na jednu stranu komerční software na GNU/Linuxu chce málokdo, na druhou stranu by to přineslo do vývoje nemalé peníze...

[Jendа]

Nutno podotknout, že ten komerční software je mnohdy fakt prasácky zabalený, instalátor ho různě rozhází po systému, neumí si po sobě uklidit atd. To je také příčinou toho samovolného zpomalování Windows a nutností různých těch registry cleanerů.

[Grunt]

To je jenom důsledek.

[Grunt]

Je to svým způsobem elegantní, především z hlediska výrobce softwaru.

No rozhodně mi to nepřijde moc elegantní z pohledu systému.

To je pravda, zase na woknech (a i na Macu ostatně..) je spousta komerčního softwaru. To je ten kámen úrazu.

A komerční a otevřený, to se nějak vylučuje?

Faktem je že na jednu stranu komerční software na GNU/Linuxu chce málokdo, na druhou stranu by to přineslo do vývoje nemalé peníze...

Ale také všechny nevýhody s tím související.

[Grunt]

Stačí k linkeru nebo překladači dotlačit parametr -static. Hodně štěstí.

[Grunt]

Jinak: Viděl jsem program Renoise (ten sice nepoužívám), a ten nemá žádné závislosti, ani není určené, pro jakou distribuci a verzi Linuxu se hodí. renoise Pro instalaci programu stačí jenom nakopírovat soubor do vhodného adresáře a program je připravený k použití.

Jasně. A možná by bylo také fajn zmínit, že ten Renoise Tracker je pěkně suprově svobodný kus softu, že? To bude možná také ten důvod. A jinak ani renoise tracker není komplet staticky slinkovaný, ale má také nějaké své závislosti. Jinak doporučuju s ním zkoušet nějaké plugin nebo syntetizéry a pak člověk pochopí, že to statické slinkování(ale částečně v tom hraje roli i to, že to není OSS) rozhodně není tak růžové.

Proto nevím, proč by to tak jednoduše nemohlo jít pro kterýkoliv program.

Já nevím. Já zas včera stáhl Firefox 4. Ten komplet dynamicky slinkovaný a má spoustu závislostí a ani tak jsem s tím neměl nejmenší problém.

[Michal Vyskočil]

Většinou nějaké to ./configure --enable-static, nicméně vzhledem k tomu, že se ptáš na něco takového, bude možná nejlepší si o tom všem nejprve něco zjistit.

[DWD]

Kolik lidí v roce 2010 nemá internet? A kolik z nich používá Linux?

Například já jsem dříve neměl, ani nepotřeboval internet. Když jsem přešel na Linux, pořídil jsem si internet jenom kvůli tomu, abych mohl stahovat balíky, kvůli ničemu jinému. Kvůli takzvanému peklu závislosti by se totíž balíky na cizím internetu blbě stahovali, protože bych nemohl použít nástroj pro automatické vybírání závislostí. Kdyby balíky na sobě nezávisely, nepotřeboval bych na svém počítači internet ani teď, protože pokaždé, když bych se rozhodl stáhnout si nový program, stačilo by mi jít občas do města na internet, tam si stáhnout balík obsahující ten program, donest domů a nainstalovat.

[Filip Jirsák]

Pokud ve svém uvažování vyměníte „balík se závislostmi“ za „seznam balíků“, začne vám to fungovat. Na počítači, kde chcete instalovat, si připravíte seznam balíků i se závislostmi, a na počítači s internetem si pak ty balíky stáhnete.

[pavlix]

To mi zní hrozně pohodlně :). Zvlášť, když si s balíky přinesu ještě aktualizovanou databázi balíků.

[DWD]

Pokud ve svém uvažování vyměníte „balík se závislostmi“ za „seznam balíků“, začne vám to fungovat. Na počítači, kde chcete instalovat, si připravíte seznam balíků i se závislostmi, a na počítači s internetem si pak ty balíky stáhnete.

Ale když závislé balíky mají ještě další závislosti, tak se celý seznam najednou neudělá, aby v něm nechyběly ani ty závislosti pro hlavní balík, ani závislosti pro závislosti a tak dále. Takže by se postup musel opakovat tak dlouho, dokud nebudou všechny závislosti vyřešené.

[Filip Jirsák]

Proč by se neudělal? Samozřejmě, že se tam dají všechny závislosti. Leda byste měl nějaký balíčkovací sytém, který nemá oddělená metadata balíčků – ale to není principiální vlastnost všech balíčkovacích systémů, ale jen konkrétní implementace.

[pavlix]

Ale když závislé balíky mají ještě další závislosti, tak se celý seznam najednou neudělá, aby v něm nechyběly ani ty závislosti pro hlavní balík, ani závislosti pro závislosti a tak dále.

Kde to žiješ? Vytvoření stromu závislostí je triviální operace, kterou zvládá snad každý balíčkovací systém, co znám.

Takže by se postup musel opakovat tak dlouho, dokud nebudou všechny závislosti vyřešené.

Používáš spojení "všechny závislosti" ve dvou významech, takže je to co říkáš nejen naprosto nesrozumitelné, ale není to ani pravda.

[vogo]

No větší zmatenost jsem už dlouho nečetl...

[dolik.rce]

Vyrobit .deb balíček není nijak těžké... Ale donutit aplikaci aby se zkompilovala staticky je v některých případech prakticky nemožné. Plus všechny ty důvody popsané výše

Pokud opravdu toužíš po tom mít všechny stažené programy k dispozici i po změně systému, stahuj zdrojové kódy. Nic ti nebrání zkompilovat si je kdykoliv a kdekoliv a jakkoliv se ti zlíbí. Ale počítej s tím, že si k nim budeš muset postahovat i knihovny na kterých závisí, případně jejich zdrojové kódy.

[Matlák]

S těmi zdrojáky to dělám přesně tak. Mám doma vypálených několik DVD se zkompresovanými zdrojovými kódy od nejzákladnějších věcí jako glibc až po jednotlivé programy. Sestavit z toho funkční systém rozhodně ale není stylem "přetáhnu a spustím" ala Mac. Spíš je to celkem na dlouho (byť to v 90% případů zvládne cvičená opice, stačí jen trpělivost, zvlášť když je slabší CPU)

[Jan Drábek]

Zmatenost.

Lze vygenerovat všechny závislosti a ty potom stáhnout, ale potřeba je to opravdu výjimečně, bez netu dneska není skoro nikdo.

Proč nepoužívat statické programy je taky dobré se podívat na windows, kde velká část programů takhle slinkovaná je a je to ke vzteku, protože to nejde pořádně aktualizovat, zabírá to místo v paměti a v neposlední řadě je to nebezpečné.

[DWD]

Proč a jak je staticky linkovaný program nebezpečný?

[chrono]

Už tu dávali odkaz na dokument, v ktorom sú popísané nevýhody statických programov.

Hneď prvý bod je to, že ak je v nejakej knižnici chyba, tak sa všetky programy, ktoré tú verziu používajú musia znova skompilovať/zlinkovať a je dosť pravdepodobné, že si už nikto nebude pamätať, ktoré programy používajú presne tú verziu knižnice (samozrejme sa dá stále skompilovať celý systém, ale to by ten používateľ pravdepodobne nič iné ani nerobil).

[progdan]

Dalsim duvodem PRO dynamicky linkovane baliky je podle me vyssi bezpecnost - pokud je v nejake knihovne (bezpecnostni) chyba, tak po aktualizaci knihovny se oprava projevi ve vsech programech, ktere ji dynamicky linkuji.

Pokud bychom predpokladali distro s vyhradne staticky linkovanymi baliky, musel by distributor pri kazdem updatu knihovny prekompilovat vsechny programy, ktere na ni zavisi - predstavte si, ze by vysla treba nova glibc - to by znamenalo prekompilovat polovinu distribuce...a to uz se vazne nevyplaci.

[Miloslav Ponkrác]

Zase jakmile jednou napíchnete a cracknete dynamickou knihovnu, tak bez práce jste napíchl všechny programy, které na tom závisí.

Zvláštní je, že třeba nikdo nešetří data tak, že je uloží jen na jedno místo. Všichni vědí, že když to jedno místo zhavaruje, data jsou v háji. Nikdo nebude tvrdit, že jedno místo je lepší, než více míst z hlediska bezpečnosti dat.

Ve skutečnosti ohledně .so to chce tvrdit spousta. Já se vsadím, že mnohem bezpečnější při vypsání pro a proti by se ukázaly statické knihovny.

A pokud nutně musíte při nové verzi knihovny překompilovat vše, co jí kdy použilo, tak je mi Vás líto. Pokud důvodem nové verze není bezpečnostní chyba, pak není důvod. Nehledě na to, že několik málo základních knihoven být klidně sdílených může, ale mělo by to být naprosté minimum.

Čím více programů danou knihovnu používá, tím spíše je crackersky cennjší tu knihovnu napíchnout. A vzhledem k tomu, že neexistuje a nikdy existovat nebude dokonale bezchybný a zároveň dokonale nenapadutelný kód, tak každá .so i každý program se dá napíchnout. Je jenom otázka, jak moc mi to stojí za to a kolik peněz za to (v porovnání s náklady na craknutí) bude. O nic jiného až tak moc nejde.

Crack jedné široce používané knihovny je daleko cennější a také systém daleko více ohrožující.

[chrono]

Čiže keď sa nájde chyba v nejakej knižnici, tak to problém je, ale to, že sú teda nebezpečné všetky staticky zlinkované programy používajúce tú knižnicu už problém nie je?

Navyše opraviť jednu knižnicu a odstrániť zraniteľnosť všetkých programov, ktoré tú knižnicu využívajú je asi jednoduchšie, ako zisťovať, aká knižnica bola použitá pri statickom zlinkovávaní nejakého programu a hľadať verziu, ktorá obsahuje upravenú knižnicu.

[Martin Mareš]

Já se vsadím, že mnohem bezpečnější při vypsání pro a proti by se ukázaly statické knihovny.

Tak sem s nějakým pro

Váš argument by mohl fungovat jedině tehdy, kdyby bezpečnostní chyby byly záležitostí několika málo konkrétních verzí knihovny, takže by pravděpodobnost, že dva programy obsahují knihovnu ve verzi s chybou, byla mizivá. Jenže to se téměř nikdy neděje, chyba je většinou přítomna ve všech verzích starších než nějaké datum.

[Grunt]

Výhoda dynamicky linkovaných balíků je ta, že se šetří místo na disku: Když několik programů bude potřebovat stejné knihovny, stačí, když ty knihovny budou v systému jenom jednou a nemusí být obsažené v každém programu zvlášť a nemusí se takto knihovny opakovat. Další výhoda je, že se šetří paměť: Když budeme mít spuštěné současně několik programů a každý bude potřebovat stejné knihovny, stačí, když se do paměti načtou jenom jednou a nemusí se načíst pro každý program zvlášť.

Není to jen o tom. Je to o tom, že většina programů je poslepovaná ze spousty součástí. A jednotlivé součásti se neustále vylepšují (zrychluje se jejich běh, uzavírají se bezpečnostní díry) a není bez problému jakoukoliv z nich za běhu pod nohama vyměnit za aktuálnější. Třeba dřív se různé transformace cpaly do kodeků přímo jako zdrojáky, ale dnes se s velkou slávou přechází právě na knihovny. Stejnětak kompresní algoritmy. Některé programy jdou dokonce tak daleko, že i svoje součásti nabízejí jako knihovny i když nemusí (, ale to už je fakt hnus). Prostě seznam výhod sdílených knihoven by byl aspoň tak na jednu stránku.

Přes všechny výhody dynamicky linkovaných balíků bych dal přednost staticky linkovaným balíkům, protože ty mají proti dynamickým zase jiné výhody a ty se mi zdají být o hodně větší.

Už se to zkoušelo u různých GNU distribucí (dokonce i BSD – viz PC-BSD), ale nakonec se to zase vrátilo, protože je to pěkně na høvnø.

Přesto většina balíků je ale dynamických, zřejmě si většina lidi myslí, že jsou lepší.

Většina lidí si to nemyslí, ale většina lidí to ví. A vychází při tom z více než pětadvacetileté zkušenosti.

U statických balíků neexistuje tak zvané peklo závislostí.

Tam zas existuje jiné peklo. Stačí si vzít jako příklad operační systém Windows. Doporučuju někdy si tam pohrát s GNU balíkama. To je peklo jak pro vývojáře, tak pro uživatele. Windowsáci mají GNU (společně s balíkovacíma systémama) opravdu co závidět.

Ti nemůžou využít automatické řešení závislosti. Nezbývá jim nic jiného, než postupovat takto: Vyberou si nějaký program. Půjdou někde, kde je internet. Tam si stáhnou a vypálí potřebný balík. Donesou ho domů a pokusí se ho nainstalovat. Dostanou odpověď, že balík nejde nainstalovat, protože chybí závislé balíky. Závislé balíky si zapíšou a půjdou znovu na internet. Zase si je stáhnou a vypálí a donesou domů. Zase dostanou odpověď, že ty nové balíky nejde nainstalovat, protože k těm novým balíkům chybí další závislosti. A tak se to může opakovat třeba i víckrát za sebou, než bude možné jeden program nainstalovat.

A nebo stačí dát balíčkovacímu systému přepínač aby postahoval vše i se závislostma a na cílovém počítači je jen stačí všechny označit a dvakrát kliknout.

U statického balíku se to stát nemůže.

Jasně, ten zas může jenom sletět na nekompatibilní verzi libc knihovny.

Další výhoda statických balíků: Statický balík je kompatibilní s různými distribucemi a verzemi Linuxu, je víceméně univerzální.

Narozdíl od dynamických. Dynamické balíky pasují jenom do te svoje dystribuce a verze Linuxu a do dalších už ne. Proto u dynamických balíků je nevýhoda.

Není úplně tak pravda. Viz o něco výše. A v případě, že už binárka je kompatibilní s verzí libc knihovny, tak je egal jestli je statická nebo dynamická. Stejnětak závislosti ostatních knihoven, protože většinou si sebou táhnou programy min. požadované verze knihoven.

Pokud to byl pro nás důležitý program, jsme v pytli.

Proč by jsme byly v pytli, když jsou ke všemu zdrojáky? A snad nejsi lama, ne?

Vyměníme operační systém a balíky, které máme vypálené, si znovu nainstalujeme do nového Linuxu. Balíky budou pěkně přenositelné z jednoho Linuxu do druhého.

Ty by sis asi měl vyjasnit co je to distribuce GNU systému. Když si nainstaluješ jinou distribuci, přeinstaluješ ji balíkama z původní verze, tak v čem se asi bude lišit?

Někdo by mohl říct, že budeme mít zastaralé programy. To vadí?

Ano vadí.

Ta jistota, že budeme mít stále všechny programy, na které jsme zvyklí, za to stojí

Ne, nestojí.

Další příklad: Budeme si chtít stáhnout a nainstalovat novější verzi některého programu nebo nějaký nový program, který předtím neexistoval a vznikl nedávno. Pokud jsou balíky dynamické, není to tak jednoduché. Jsme omezení jenom tím, co najdeme v repozitářích pro náš Linux. Když v nich požadovanou verzi programu nebo požadovaný program nenajdeme, musíme buď kompilovat, nebo přejít na novější verzi Linuxu, která už má v repozitářích to, co potřebujeme. Zase musíme kvůli jednomu programu vyměnit celý operační systém a spolu s ním i další programy. Prostě všechno musíme zahodit a začít zase od nuly. U statických balíků se to stát nemůže. Tam, když si chceme pořídit jiný program, nebo jinou verzi programu, můžeme, aniž bychom museli vyměňovat celý operační systém a všechny ostatní programy.

Různé distribuce mají různé způsoby. Ubuntu má PPAčka, Fedora/Debian má unstable, Gentoo má odmaskování experimentálních balíků. A stejně když budeš stahovat nějakou experimentální verzi čehokoliv, tak s největší pravděpodobností k nim budeš muset stáhnout i experimentální verze závislostí (ke git verzi programu, třeba git verzi některých knihoven). Takže v čem si jako pomůžeš?

U statických balíků můžeme nezávisle na sobě vyměňovat programy, verze jednotlivých programů, verzi a distribuci Linuxu. Prostě všechno, nebo skoro všechno je kompatibilní, dá se různě kombinovat.

Jakože u dynamických nic takového dělat nemůžeš? To zas odkdy?

Nakonec bychom nemuseli být omezení jenom na repozitáře pro naši přesnou verzi a distribuci Linuxu, mohli bychom použít skoro jakékoliv repozitáře, což by se hodilo především v případě, kdyby repozitáře pro naši verzi Linuxu z internetu náhodou zmizely.

Používání oficiálních repositářů má také svůj důvod.

Kdyby byly všechny balíky statické, měli by ušetřenou práci taky výrobci balíčků. Nemuseli by vyrábět balíky pro každou distribuci a verzi Linuxu zvlášť, protože by balíky byly víceméně univerzální. Stačilo by vyrábět jenom balíky zvlášť pro RPM, DEB a podobně, pro 32 bitů, pro 64 bitů, a už by nemuseli dělat zvlášť pro různé distribuce a verze Linuxu. Nebylo by potřeba s každou novou verzi Linuxu dělat tisíce balíků do nových repozitářů, stačilo by je jenom okopírovat. Jenom v případě, že by vznikl nový program nebo nová verze programu, musel by se udělat nový balík, aby i na to existoval hotový balík.

?

Tady by si měl někdo opravdu ujasnit proč se to všechno dělá.

Není to vynikající?

Nebylo by to vynikající?

Není to pěkné?

Ne, není. Je/bylo by to pěkně na p**u.

[Grunt]

Tam zas existuje jiné peklo. Stačí si vzít jako příklad operační systém Windows. Doporučuju někdy si tam pohrát s GNU balíkama. To je peklo jak pro vývojáře, tak pro uživatele. Windowsáci mají GNU (společně s balíkovacíma systémama) opravdu co závidět.

Teda ať nemluvím za jiné. Sám jsem si to zkoušel. Jak PC-BSD, tak dělání binárek svobodného softu pod majoritním operačním systémem. Ano, ze začátku je to možná super, ale po jisté době to začne pěkně srát.

BWT: Ten Linux, to je zas co? Nějaký operační systém?

[Matlák]

Uvědom si že autor postu se na to dívá z hlediska naprostého BFU, kterého zajímá jen dostupnost co největšího množství software, a to stylem "stáhnout a spustit" jako na Windows, či lépe na Macu. Nějaká konzistence v rámci systému, či vylepšování knihovních algoritmů ho vůbec nezajímá. On jen chce používat to na co si zvykl a co mu vyhovuje... podobně jako typický uživatel Macku či Wokýnek.

ps. ten překotný vývoj knihoven může být občas kontraproduktivní. Spoustu věcí člověk nemůže zkompilovat proti novějším knihovnám, protože se změnilo API... takže nějaká zalepená bezpečnostní díra je mu na dvě věci...

[Grunt]

Uvědom si že autor postu se na to dívá z hlediska naprostého BFU, kterého zajímá jen dostupnost co největšího množství software, a to stylem "stáhnout a spustit" jako na Windows,

Tak se na to dívá ze špatného pohledu a měl by si uvědomit, že GNU není systém určený lamám.

Nějaká konzistence v rámci systému, či vylepšování knihovních algoritmů ho vůbec nezajímá. On jen chce používat to na co si zvykl a co mu vyhovuje... podobně jako typický uživatel Macku či Wokýnek.

Jasně. Jenže bohužel to někdo řešit musí. A většinou jsou to vývojáři těch programů. A doporučuj poslechnout si někdy ty, jak u toho nadávají jak špačci.

ps. ten překotný vývoj knihoven může být občas kontraproduktivní. Spoustu věcí člověk nemůže zkompilovat proti novějším knihovnám, protože se změnilo API...

Když se změní API nějakého backendu, tak se tomu většina frontendů přizpůsobí a pak jsou verze programů, které jsou funkční s určitými rozsahy verzí backendů. Uznávám, že to není úplně nejideálnější, ale většina programů si to aspoň teď hlídá. V minulosti to bývalo mnohem horší.

[DWD]

Proč by jsme byly v pytli, když jsou ke všemu zdrojáky? A snad nejsi lama, ne?

Jsou, ale co když se některý program přestane vyvíjet a už nepůjde sehnat ani balík, ani zdroják? A to nejen novější verze programu, ale ani staré. A zrovna jak naschvál se může jednat o program, který je pro někoho důležitý. To už by byl opravdu v pytli. Nebo to nehrozí?

[Grunt]

Jsou, ale co když se některý program přestane vyvíjet a už nepůjde sehnat ani balík, ani zdroják?

Proč by neměl jít sehnat zdroják? Např. u GPL je to podmínka, že pokud k něčemu seženeš binárku, měl si k ní sehnat i zdroják.

[DWD]

A to i u velmi zastaralých programů, které se dávno přestaly vyvíjet? (pokud něco takového může být)

[saerzh]

nechtˇ je pak statiscky slinkovaný v /opt. Myslím že k tomu je ten adresář mimo jiné určen.

[Grunt]

Pro velmi zastaralé programy neplatí GPL? Nebo nechápu co to furt s těma velmi zastaralýma programama máte.

[DWD]

Myslel jsem, když se některý program přestane vyvíjet a nepůjde sehnat ani binárka, ani balík, tak jestli půjde sehnat aspoň zdrojový kód.

[Grunt]

Určitě. Většina otevřených projektů se někde hostuje a odtuď je nevyhazují. Nějký GIT, SVN nebo něco podobného by mělo být dostupného vždy. Dokonce se většinou zálohují i starší verze, takže není třeba problém narazit na Linux verze 0.1.

[Měto]

Díky, tenhle komentář tu byl potřeba.

[Radek Miček]

Na existující programy lze použít Ermine případně statifier.

[xxxxxxxxxxx]

No já bych to viděl asi takhle: Základní systém zkompilovanej dynamicky včetně Xorg a KDE a zbytek programů tvořit staticky. Sem taky pro statický balíky.

[Měto]

Doufám, že podobně blbé názory nemáš i v jiných oblastech života, třeba v politice

[xxxxxxxxxxx]

Proč blbé? Nějaká logická chyba? ))

[pavlix]

Statickou kompilaci nechci až na velmi výjimečné případy (servisní jednoúčelová binárka apod). Z důvodů:

1) Nutnost překompilovat skupinu balíčků při změně knihovny.

2) Nutnost překopmilovat prakticky celý OS při změně nějaké zásadní knihovny.

3) Nemožnost "lehkých" bezpečnostních aktualizací.

4) Nemožnost transparentních vylepšení (aplikace se nezměnila, přesto má díky update knihovny novou funkcionalitu).

5) Plýtvání místem.

Dynamické natahování duplikovaných knihoven (co závislý balíček, to individuální kopie) nechci z důvodů (3), (4) a (5), až na výjimečné případy, kdy to nelze rozumně řešit balíčky.

Dynamické linkování napříč balíčky je ok, jen je potřeba knihovny pečlivě verzovat.

[Ivan]

Jeste muze existovat jeden duvod - zabugovana aplikace. Predstavte si hypopeticky problem

ldd /usr/bin/evolution | wc -l
135

A ted se pokousite autorovi aplikace reportovat chybu, ktera nastava jen u vas, prestoze mate stejne zdkojaky jako on. Chyba bude nejspis v jedne z tech 135ti knihoven. U staticky slinkovanych aplikaci muzete snaze poslat core autorovi k prozkoumani. U dynamicky linkovanych programu se taky muze stat, ze se stejna chyba bude projevovat ruzne.
Wokenni debuger umi stahovat z webu debug symboly ke knihovnam na zaklade checksum-u. Bylo by pekny kdyby slo otevrit v gdb core a debuger by si stahnul z webu redhatu vsechny debug symboly a rek by vam s jakyma knihovnama to spadlo. Pripojovat ke kazdymu bugreportu vystup z rpm-qa je naprd.

[Grunt]

Pravda. Debugování. To asi nikoho nenapadlo. Hledat kde v statické binárce se to dostalo až tak daleko, že jádro odeslalo pozdrav v podobě SIGSEGVu by určitě nebyla sranda. Jenže když nejsou symboly, tak backtrace aspoň vypíše jména knihoven a člověk už přeci jen trošku tuší (když zas symboly jsou, tak jsou místo jmen knihoven jména zdrojáků, což může být u pěkně rozvětveného bt na prd). A nebo se dá láp sledovat komunikace mezi jednotlivýma procesema odchytáváním pomocí ltrace.

Wokenni debuger umi stahovat z webu debug symboly ke knihovnam na zaklade checksum-u. Bylo by pekny kdyby slo otevrit v gdb core a debuger by si stahnul z webu redhatu vsechny debug symboly a rek by vam s jakyma knihovnama to spadlo.

Tak to řekne i bez symbolů a jinak přesně toto gdb ve Fedoře dělá. Když nejsou symboly, tak se zeptá a pak je pomocí rpmka stáhne. A nebo to ještě dělá abrtd, když se klikne na Report.

[petr_p]

A už jste to zkoušel? Protože Red Hatem opatchované gdb, když najde kód bez ladicích informací, uživateli rovnou vyplivne příkaz, kterým si chybějící údaje může doinstalovat. A funguje to i s dynamickými knihovnami.

[Michal Vyskočil]

Nejenom RedHatem, prakticy kdokoli, kdo poskytuje debug(info) balíčky s ladícími symboly, má podobný patch v gdb.

[Grunt]

Kdokoliv ne. Třeba Ubuntu ne:

Reading symbols from /bin/cat...(no debugging symbols found)...done.

To s tím přijde až jako poslední.

[Ivan]

Dik za tip. Zkousel jsem to casto ale na spatnym hrobe. V Ubuntu to nechodi a v praci sice mame RHEL a ale jeste bude nejakou dobu trvat nez 21. stoleti dorazi i k nam.

PS: v tomhle nejak nechapu politiku Ubontu oni sice distribuji baliky s debug symbolama, ale pouze pro cca 20% baliku? Podle ceho to vybiraji?

[DWD]

Statickou kompilaci nechci až na velmi výjimečné případy (servisní jednoúčelová binárka apod). Z důvodů:

1) Nutnost překompilovat skupinu balíčků při změně knihovny.

2) Nutnost překopmilovat prakticky celý OS při změně nějaké zásadní knihovny.

Proč by se kvůlo změně knihovny předělávat několik balíků, kvůli tomu, že by ta knihovna byla obsažená ve více balíkách? Nestačilo by předělat jenom ten balík, u kterého tu novější knihovnu chceme mít? Jenom ten program, u kterého je důvod vyměnit knihovnu za novější. Nemusí přece všechny balíky, ve kterých je určitá knihovna, mít stejnou verzi te knihovny.

[danaketh]

V knihovně byla bezpečnostní díra, umožňující útočníkovi získat vládu nad běžící aplikací. Nová verze knihovny díru opravila. Máš na výběr - buď opravit všechny výskyty nebo žít s tím, že tam máš díru :)

Nemusí jít jen o možnost ztrácy citlivých dat (kdo něco takového v PC má?). Hádám, že by třeba grafika naštvalo, kdyby mu během práce někdo smazal pár vrstev ve Photoshopu. Ono by asi naštvalo i sekretářku, kdyby jí šéf nadiktoval dopis a někdo jí ho smazal...

[DWD]

V knihovně byla bezpečnostní díra, umožňující útočníkovi získat vládu nad běžící aplikací.

To by nám musel někdo po internetu vlést do počítače. To je tak lehké?

[rADOn]

Pletes si pricinu a nasledek. Pokud mas deravy aplikace, muze ti nekdo vlezt tema dirama do pocitace. Ne naopak.

[JS]

Ja myslim, ze to zavisi na situaci. Pokud je to uzavreny program (neni k nemu zdrojak, neni v repozitari), at je radeji zkompilovan staticky. Uz se mi stalo, ze jsem pro neco potreboval libc verze 1.2 nebo kolik (proste cca z dob Redhat 5 nebo tak). (Je sice pravda, ze vyrobce muze ty knihovny pribalit, ale muze to neudelat, jako v tomto pripade, protoze si mysli, ze jsou standardni, a pak jste v...)

Pokud k nemu je zdrojak, nebo je v repozitari, at se probuh kompiluje dynamicky. V takovem pripade staticka kompilace nedava zadnou vyhodu.

Takze, neni jedno lepsi nez druhe, a oboji ma sve misto.

[Martin Mareš]

Mně přijde, že se snažíte (jak už naznačili jiní, třeba pan Drepper, tak trochu nešikovně) řešit jeden speciální případ obecného problému, totiž toho, že dnešní programy obvykle nevznikají ve vakuu, nýbrž jsou složené ze spousty samostatně vyvíjených částí. Někdy těmi částmi jsou knihovny, jindy jiné programy, nebo třeba fonty. A sotva dává smysl s knihovnami zacházet jinak než s jinými druhy komponent.

Jistě by na první pohled fungovalo, kdyby si každý program s sebou nesl úplně všechny komponenty, na kterých závisí, ale vzato do důsledku, často by si táhl kopii skoro celého systému. Například kdyby v libovolném svém skriptu spouštěl cat, musel by mít svou kopii /bin/cat

To je jednak nebetyčné plýtvání místem, druhak se často stává, že se různé verze téže komponenty nesnesou pohromadě, například proto, že mají různý formát datových a konfiguračních souborů. (Líbilo by se vám mít ve svém home několik kopií .vimrc jen proto, že si programy s sebou přitáhly několik různých verzí Vimu?)

Globální systém pro správu balíčků, který se stará o závislosti, mi zatím opravdu přijde jako jediné funkční řešení.

[pht]

Globální systém pro správu balíčků, který se stará o závislosti, mi zatím opravdu přijde jako jediné funkční řešení.

Nejsem si jistý jestli to ještě někdo nezkoušel ale daleko funkčnější by mi přišlo kdyby kromě správy balíčků se také zabýval správou konfigurace systému, popř. i správou revizí. Tedy nějak to propojit s ostatními "správci".

[DWD]

Taky se mi líbí formát run pro aplikace. Pokud se nepletu, má to taky výhodu, že takový soubor netrpí závislostmi, a taky není určeno, do které verze a distribuce Linuxu se hodí, je kompatibilní se všemi. Dokonce není určeno, jestli je to pro RPM distribuce nebo DEB distribuce a další, pasuje do všeho. Další výhoda je ta, že takový soubor se nemusí instalovat; stačí uložit do počítače, třeba do některého domácího adresáře, nastavit mu právo spouštět a už je připravený ke spouštění a můžeme rovnou používat. Škoda, že se běžně nadají sehnat aplikace v tomto vynikajícím formátu nebo škoda, že si ho neumím ze zdrojových kódů vyrobit sám. Je to těžké? Jak bych se to mohl naučit?

[rADOn]

nebo škoda, že si ho neumím ze zdrojových kódů vyrobit sám. Je to těžké? Jak bych se to mohl naučit?

Internalie .run neznam ale principielne to bude neco zhruba nasledujiciho:

1) zkopilujes s --prefix nekam do /tmp/foobar (plus opravis dalsi cesty pokud jsou potreba)

2) binarky projedes lddckem a vsechny knihovny co uvidis pridas k baliku, rekneme do lib/

3) opakujes bod 2 s knihovnami knihven, dokud nedojdes k zaveru ze mas dost - nejpozdeji az narazis na libc

4) zabalis do shar archivu tak aby se rozbalil tam kde mas nastaveny prefix a spustil s LD_LIBRARY_PATH obsahujicim na pribalene knihovny.

Ruzny programy budou potrebovat ruzne poladit ale v principu je to afaik neco takovyho. Rozbal si nejaky .run archiv a uvidis sam. A taky uvidis proc to ve skutecnosti nemuze spolehlive fungovat

[pavlix]

Pokud se nepletu, má to taky výhodu, že takový soubor netrpí závislostmi, a taky není určeno, do které verze a distribuce Linuxu se hodí, je kompatibilní se všemi.

Takhle to nefunguje. Přibalené knihovny nejsou všechno, narazíš na spoustu problémů při komunikaci se zbytkem systému. Dobrým příkladem je zvuk.

[VSi]

Zdá se mi, že dost velký problém linuxu pro desktopové použití je, že věci jako zvuk nebo ovladače HW a podobné nemají nějaké standardní a hlavně zpětně kompatibilní rozhraní. U open source aplikací z repozitářů to tak nějak nevadí, i když to přináší stálou práci navíc.

Srovnávám se světem Windows, kde jsou mnohé věci řešeny podstatně hůře než na Linuxu, ale fakt je, že většina aplikací i z dob Windows 95 bez potíží běží na nejnovější verzi systému. Podstatné je tohle hlavně u komerčních uzavřených apliakcí. Můžete sice říkat, že otevřené jsou lepší, a takovými problémy netrpí. Ale uzavřené aplikace tu prostě jsou a obrovské množství lidí je z nějakého důvodu používá. Běžne potřebuje provozovat aplikace, které výrobce už nepodporuje, resp. výrobce vůbec neexistuje.

Pravda, že s ovladači HW je to na Windows mnohdy taky špatné. Hlavně pro staší HW. Ale když se podívám na Nvidia ovladače, tak Linux k nim není zrovna přívětivý - problémy při updatu X.org a jádra. Neznám tu situaci přesně, ale věřím, že pokud by byla možnost, Nvidia ty ovladače udělá lepší a kompatibilní. Nemůžete po nich ale chtít, ale je udělali open source, což by asi bylo řešení těch problémů. To je skutečně alespoň trochu stabilní API pro ovladače v linuxu takový problém? Ať už technický nebo licenční.

[pavlix]

Zdá se mi, že dost velký problém linuxu pro desktopové použití je, že věci jako zvuk nebo ovladače HW a podobné nemají nějaké standardní a hlavně zpětně kompatibilní rozhraní. U open source aplikací z repozitářů to tak nějak nevadí, i když to přináší stálou práci navíc.

Blýská se na lepší časy. A vůbec se v posledních letech hodně zlepšilo. Ale v tomhle máš podle mě pravdu.

Srovnávám se světem Windows, kde jsou mnohé věci řešeny podstatně hůře než na Linuxu, ale fakt je, že většina aplikací i z dob Windows 95 bez potíží běží na nejnovější verzi systému.

Na windows je to trochu jinak, poskytují určité vrstvy kompatibility se staršími verzemi. Na Linuxu to není tolik potřeba, i když třeba ALSA poskytuje kompatibilitu s OSS a najdeš mnoho dalších příkladů. Samozřejmě lze v Linuxové distribuci implementovat zpětnou kompatibilitu nebo standardizovat rozhraní. A myslím, že spousta rozhraní je standardizovaných na Linuxových distribucích lépe.

Ale uzavřené aplikace tu prostě jsou a obrovské množství lidí je z nějakého důvodu používá. Běžne potřebuje provozovat aplikace, které výrobce už nepodporuje, resp. výrobce vůbec neexistuje.

Právě z tohoto důvodu jsem pro částečnou eliminaci uzavřeného software, protože má kratší životnost. Tam, kde se uzavřenému software nelze vyhnout, je asi nejlepší udržovat nějakou vrstvu kompatibility (příkladem může být třeba i wine), která je ale potřeba vyvýjet i s ohledem na konkrétní aplikace.

Linux k nim není zrovna přívětivý

Ústupky uzavřeným ovladačům považuju za nepřístupné (až na výjimky). Jejich vliv na budoucí použitelnost hardware je příliš zlý.

Nemůžete po nich ale chtít, ale je udělali open source, což by asi bylo řešení těch problémů.

Ano přesně to od ovladačů hardware očekávám. Ať už jsou od výrobce nebo ne, chci je opensource a tím pádem dlouhodobě udržitelné bez ohledu na vůli výrobce. Uzavřené ovladače slouží hlavně k držení uživatelů jako rukojmích a vynucování upgradu hardware.

To je skutečně alespoň trochu stabilní API pro ovladače v linuxu takový problém?

Stejně jako na windows, je to o těch vrstvách kompatibility. Navíc toto je oblast, kde probíhá dost živý vývoj (a to nejen na Linuxu).

To je skutečně uvolnění specifikací za účelem umožnění vývoje opensource driverů (ani neni potřeba aby je firma sama vyvíjela), takový problém? Pokud ano, tak to rozhodně není problém můj.

Za sebe s tímto vůbec nemám problém a používám prakticky výhradně opensource drivery. A použitelnost grafických karet posuzuju právě ve spojení s OSS drivery, pro svoje účely. Takže pokud OSS drivery neumí 3D, posuzuju (opět pro sebe) kartu jako kartu bez 3D.

Ale chápu, že jiní to vidí jinak.

[VSi]

Jasně, s těmi ovladači záleží na použití. Velká většina počítačů si víc než vystačí s grafikou na úrovni posledních integrovaných Intel, kde jsou linuxové ovladače takové, jaké by měly být - tj. otevřené, Intel je sám vyvíjí, spolupracuje. I když je kvalita těch ovladačů proměnlivá, kvůli rychlému vývoji X serveru a změnám v kernelu.

Bouhužel 3D grafické karty jsou dost speciální hardware. Ty karty existují, pořád se zlepšují, a používají se i na jiné věci, než hry (i když i hry jsou legitimní požadavek). Takže je tu skupina lidí, kteří potřebují využít výkon těch 3D grafik naplno. A chtějí to i na Linuxu - Nvidia karty pro profesionální segment se na Linuxu používají hodně, tedy tak hodně, že je to pro výrobce zajímavá oblast.

Potíž je v tom, že zrovna u těch grafik je dost podstatná část know-how a nákladů vložena právě do těch ovladačů (Nvidia to alespoň tvrdí). Samotný hardware toho moc neumí, je programovatelný. Čili výrobce z velké části vydělává na těch ovladačích. Dají se považovat za komerční uzavřený software, poskytují výrobci konkurenční výhodu.

Může být situace, že by otevření ovladačů znamenalo pro výrobce sebevraždu ve smyslu toho, že se objeví X dalších firem, které nabídnou nižší cenu, protože neměly náklady s jejich vývojem. To je ta situace, kdy podle mě po výrobci nelze požadovat plně otevřené ovladače. U jiného HW může být situace zcela jiná.

[Martin Mareš]

Právě že po Nvidii nikdo nepožaduje otevřené ovladače, nýbrž dokumentaci od hardwaru, aby si komunita mohla ovladače napsat sama. I tu se ovšem Nvidia sveřepě brání vydat.

[pavlix]

Potíž je v tom, že zrovna u těch grafik je dost podstatná část know-how a nákladů vložena právě do těch ovladačů (Nvidia to alespoň tvrdí). Samotný hardware toho moc neumí, je programovatelný. Čili výrobce z velké části vydělává na těch ovladačích. Dají se považovat za komerční uzavřený software, poskytují výrobci konkurenční výhodu.

Ať si tvrdí, co chtějí. Spousta lidí dává přednost OSS driverům (ať už znalých nebo neznalých, v druhém případě třeba i nevědomky) a tudíž budou tu grafickou kartu považovat za velmi slabou, protože s OSS drivery taková opravdu bude.

Může být situace, že by otevření ovladačů znamenalo pro výrobce sebevraždu ve smyslu toho, že se objeví X dalších firem, které nabídnou nižší cenu, protože neměly náklady s jejich vývojem. To je ta situace, kdy podle mě po výrobci nelze požadovat plně otevřené ovladače. U jiného HW může být situace zcela jiná.

Otevření ovladačů je něco, co nikdo po nikom nechce. Pokud někdo otevře ovladače, tak se mu tleská, ale požadovat to nelze.

Linuxová komunita včetně té firemní požaduje pouze zpřístupnění specifikací.

Velká většina počítačů si víc než vystačí s grafikou na úrovni posledních integrovaných Intel, kde jsou linuxové ovladače takové, jaké by měly být - tj. otevřené, Intel je sám vyvíjí, spolupracuje.

Ano, to jsou jedny z mých nejoblíbenějších :). Na pracovní stanici stokrát lepší než cokoli s closedsource drivery.

Takže je tu skupina lidí, kteří potřebují využít výkon těch 3D grafik naplno.

Takhle, do 3D se nechci míchat, je to úplně mimo moji oblast zájmu.

Co mě zajímá, jestli výrobce umožnil tvorbu plnohodnotných OSS driverů s 2D akcelerací, nebo se na jejich vývoji dokonce aktivně podílel. Takové produkty mi vyhovují, i kdyby to znamenalo, že je potřeba pro 3D instalovat nějaký closed source doplněk (který osobně nepotřebuju).

Ať to funguje skvěle na opensource na 2D a budu relativně spokojený.

[pht]

narazíš na spoustu problémů při komunikaci se zbytkem systému. Dobrým příkladem je zvuk.

Tak zrovna u zvuku jsem zvyklý na toto: dříve bylo OSS, nyní je alsa. Alsa je s OSS plně zpětně kompatibilní (v některých případech je alsa emulace lepší než původní OSS). Jestli nějaké postmoderní pulse-sračky tato pravidla porušují tak je to jen o důvod víc je hodit do koše.

[pozortucnak]

Univerzální instalátory? Nepodobá se náhodou klik tomu jak to funguje v Mac OS X? Mno dále tu máme autopackage, a zero...

[DWD]

Vylepšil jsem článek.

[bleky]

No... tys tomu dal. Taková snůška blábolů, to jsem dlouho nežral... naposledy na jiném tvém příspěvku.

Dynamické linkování má jednu zásadní výhodu - šetří paměť RAM. Mít staticky linkované např. KDE, tak se nevejdeš do 2G RAM. Je vidět, že víš fakt kulové o tom, jak funguje počítač,linux a podobně.Fakt,raději nic nepis.A nebo pis,aspon se tu lidi pobavi...

A bohuzel je to tak,ze linux je spojen s internetem uz od sveho vzniku, takze argument 'pokud nekdo nema net' je v dnesni dobe "netu za dve kila" je alibisticky - dnes si jej muze dovolit opravdu kazdy,kdo jen trochu chce!