GoboLinux 015 (diskuse)

[jadd]

Ještě žádný komentář? Pročetl jsem celý FAQ, ta distribuce mi je sympatická, souhlasím s tím názorem, že je v tom lepší přehled ke kterému daná knihovna patří atd. Je ale škoda, že nepoužívají ve složce Programs strukturu použitou v Portage např. v Gentoo, je to tam přehledně roztříděný, že člověk má lepší přehled, k čemu to tak asi slouží, pokud to název přímo neříká. Distribuce asi začla s vývojem dřív..? Ačkoliv třídění v Portage už bylo ve FreeBSD také.

[098347iuahf]

Bylo by to zbytecne komplikovany. U portu je to neco jinyho. V kazdym pripade ta distribuce se mi taky libi.

[chrono]

Ako si mi uniká zmysel, kedže namiesto súborov na štandardných miestach tam bude kopec odkazov.

[jadd]

Odkaz je snadno rozpoznatelný, netřeba přes něj chodit.

[mankind_boost]

Odkazy jsou skryté (pomocí modulu v kernelu).

[potato]

To je doufám vtip.

[Václav "Darm" Novák]

Ne, jen volitelná vlastnost.

[luko]

Tak to potom je fajn riesenie

Co sa tyka enlightnemnetu tak to je tiez dobra volba

[potato]

Organizace souborů na disku, která potřebuje speciální podporu v jádře, aby nevypadala padlá na hlavu, je fajn řešení?

[Václav "Darm" Novák]

Nepotřebuje. Ten modul je jenom volitelná kosmetická úprava.

[mankind_boost]

Tady někdo neumí číst...

[chrono]

A nie je to potato.

[mankind_boost]

Ale ano, je. Protože už mu to někdo nahoře předtím vyvrátil.

Další adept?

[Petr Ježek]

Předně, klobouk dolů, že někdo šel takle prošlapávat závěj. Dále mám důvodné podezření, že mnoho těch, co to ocení, není a nebude. Osobně nemám rád vícepoložkové jednoúrovňové struktury tam, kde je realita mnohem složitější a strukturovanější. Vytvářet odkazy namísto přímého přístupu je takové malé pokrytectví :) Zkrátka, Gobo to z pochopitelného důvodu nemá a nebude mít lehké...

[jadd]

Asi je to inteligentně zakódovaný text, protože nemůžu rozluštit, co se v něm píše (a to si nijak nefandím)?

[luko]

Ono nejde o to ze to vyzera ako windos ale to ze aj to je riesenie ako zoradit subory a osvedceny. Vyhoda tohto riesenie co tu nikto nespomenul je ta ak tomu dobre chapem ze mozes mat nainstalovanych viacej verzii toho isteho programu v adresary /Programs dalsia vec co mana gobolinuxe sice starsej verzie prekvapila ked som ju poslednykrat sskusal bol dialogovy system ktory pouziva instalator a utility aspon s tej programatorskej stranky.

[xkucf03]

Vyhoda tohto riesenie co tu nikto nespomenul je ta ak tomu dobre chapem ze mozes mat nainstalovanych viacej verzii toho isteho programu

To můžeš mít i při klasickém uspořádání adresářů – běžně se to používá třeba pro Javu – můžeš mít nainstalováno více JDK a pomocí update-alternatives si vybereš, která má být výchozí + si samozřejmě můžeš zavolat konkrétní verzi i bez toho (použít celou cestu nebo si nastavit PATH)

[Jan Molič]

Ty symlinky mají své výhody. Odinstalaci programu/knihovny provedete tak, že prostě smažete její adresář a následně promažete všechny symlinky z /Index, jejichž cíle neexistují. Není třeba provozovat žádnou databázi, do níž by balíčkovací systém zaznamenával, co je kde nainstalováno a k čemu to patří. Symlinky přitom nemají žádný vliv na rychlost spouštění programů, navíc tenhle přístup je možná i "unixovější" než databáze balíčkovacích systémů

[pavlix]

Jestli máš soubory uložené podle potřeby a k tomu databází příslušnosti k balíčkům nebo soubory uložené podle balíčků a k tomu databázi symlinků, co kam patří, to jsou v podstatě ekvivalentní principy. V obou případech potřebuješ každý soubor zařadit dvakrát. V podstatě bys mohl udělat nějaký virtuální filesystém, který ti to ukáže rozhozené po balíčcích i co já vím na Debianu.

GoboLinux mi připadá jako neškodná forma exhibice bez nějakého zásadního přínosu.

[the.max]

A co když teda odinstaluješ (smažeš) něco, co je použito jako závislot nějakého jiného balíčku? Právě tohle také řeší package manager. A nebo to snad funguje tak, že všechny balíčky jsou linkovaný staticky a pak si teda sebou tahají opakovaně tuny balastu místo toho, aby použili to, co už je v systému nainstalováno? Tohle mi teda moc Unixově nepřipadá, spíš mi to připomíná widlácký přístup, kdy si programy sebou tahajpi vlastni verze knihoven a nezdráhají se jimi přepsat již v systému nainstalované verze knihoven třeba i staršími, čímž rozbijou to co fungovalo a následně při odinstalaci si ty 'svoje' staré knihovny odinstalují aniž by brali ohled na další instalované aplikace? ...ale třeba to už soudruzi za těch 12 let vyřešili.

[Ivan]

Ve woknach to uz davno vyresili - rikaji tomu "manifest hell". Tohle spis pripomina Mac a OSX. Ten pristup, kdy si programy sebou tahaji tuny balastu ma taky neco do sebe. RAMka je dneska docela levna a misto na disku taky. Pokud jsou programy linkovany s tou verzi knihovny, se kterou byly vyvijeny a testovany tak mate vetsi sanci ze to bude stabilne fungovat. C++ ABI je peklo, vsechny zmeny v ABI se proste nedaji uhlidat.

[xkucf03]

Pokud jsou programy linkovany s tou verzi knihovny, se kterou byly vyvijeny a testovany tak mate vetsi sanci ze to bude stabilne fungovat.

Stabilně jako pořád stejně blbě? Viz nedávný heartbleed. Nebo se chceš spoléhat na to, že autoři všech tebou používaných aplikací vydají včas aktualizaci?

[Ivan]

No ja zrovna ted resim problem s Fedorou. Nase GUI aplikace na ni nemuze fungovat protoze nikdo nebyl schopnej za tri roky aplikovat patch na ktery maji odkaz v bugzille. Myslim, ze si praci lidi v distribucich prilis idealizujete.

Pamatuju situaci v Debianu nekdo obeslal vsechny cleny security teamu, aby nakonec zjistil, ze 10 z 12ti lidi uz na tu praci nema cas a Debianu uz se vubec nevenuji. A dneska je to snad jeste horsi, vsichni delaji akorat politiku a jen malo lidi neco koduje.

[pavlix]

Když už se namáhám s komentářem a píšu do něj odkaz v bugzille, udělám z něj link. Na jednu stranu nemá smysl si distribuční maintainery idealizovat, na druhou stranu nemá smysl ani z konkrétních případů dělat obecné pravidlo.

A dneska je to snad jeste horsi, vsichni delaji akorat politiku a jen malo lidi neco koduje.

Tomu můžeš pomoct jediným způsobem ;).

[Ivan]

V tom mas pravdu - opravdu jsem zbytecne generalizoval. A navic jsem prehanel - ten bug neni stary ani dva roky. Bugreport tady a tady. Patch je zde.

Jde o to, ze autor GUI aplikace objevil chybu v knihovne. Tu chybu opravil a build pro windows je stabilni protoze pouziva fixnutou verzi. Jedine na Fedore to nefunguje, protoze aplikace si nesmi bundlovat vlastni verze knihoven a musi pouzivat to co je v distribuci. A ja mam ted mam podobny problem, taky jsem fixnul v ty knihovne nejaky bugy a rad bych tu knihovnu pouzil i s tema fixama. A spravce baliku pro Fedoru do me furt huci abych pri kompilaci pouzival distribucni verzi. Jinak, ze je to proti policy. A najednou bych mel resit problemy cizich lidi a nutit je aby udelali neco do ceho se jim nechce a studovat nejaky jejich standarty a jeste to resit pro kazdou distribuci zvlast. Ja to delam protoze me to bavi, ale resit tuhle distribucni politiku me fakt nebavi.

[jadd]

Já nejsem zběhlej jako vy ale, Co když je to tak, že když nějakému balíku odebereš závislosti, prostě přestane fungovat. Tohle si asi budeš muset uvědomit než ho budeš chtít odstranit. Windows taky používá v Systému sdílené knihovny a statické jsou jen v uživatelských programech, kromě třeba dekoderů pro video. Nejsou náhodou sdílené knihovny očíslované hlavní verzí, což by mělo dát jistotu, že 6 nepříše 7? A jinak když nejde spustit program, který závisí na sdílené knihovně je možné ho zkontrolovat s ldd (lddconfig) a když najde chybu doinstalovat tu věc zpátky. Nebo příště nainstalovat program staticky. Já nevím co máš za distro ale pokud používáš ramdisk s obrázkem, tu knihovnu máš staticky, a pak tedy používáš distro s balastem. Asi nemá cenu vůbec sestavovat sdílené knihovny pro jiné než systémové programy a pak pokud odebereš systémovou věc řekneš si, já jsem ale vůl (to vztahuju na sebe).

[----]

nepodporují oficiálně x86_64...