Kernel panic v ArchLinuxu (diskuse)

[pasmen]

Vlezl jsem do /var/cache/pacman/pkg a po zdlouhavém testování jsem přišel na to, že pacman -U nazev_baliku.pkg.tar.xz instaluje vybraný balík (soubor)

Jak dlouho že používáš Archlinux, když jsi toto zjistil až teď?

[Amarok]

-U jsem pouzival jasne pri instalaci vlastnich zkompilovanych baliku z AUR. Spis jsem myslel, ze jsem cekal nejakou funkci v pacmanu jako downgrade z cache.

[Marek Bernát]

Keď niekto používa yogurt a vlastné balíky nepotrebuje, tak asi nemá veľkú potrebu inštalovať ručne

[Amarok]

Yaourt mam, ale nepouzivam, jelikoz z AURu skoro nic nemam a tech par programku jsem nainstaloval rucne.

[kralyk z abclinuxu]

Jak jako ručně? To jako že máš v systému programy mimo nainstalované balíčkovací systém? (make install?) To se nedoporučuje...

[Václav "Darm" Novák]

Předpokládám ručně pomocí makepkg bez asistence jogurtu.

[Amarok]

Tak tak.

[kralyk z abclinuxu]

V tom případě ale nechápu jaktože jsi nevěděl, co dělá pacman -U ... No nic, to je jedno, jen jsem byl zmaten...

[pasmen]

Bah! Kterej archař nepotřebuje vlastní balíky? Já jich mám

[pasmen@nyx ~]$ l /var/abs/local/ | wc -l
83

[Marek Bernát]

No, tak napr. ja ich tam mám presne 0 Balíky v distre mi väčšinou vyhovujú. Keď potrebujem niečo upraviť, tak je to obvykle z AURu.

[kralyk z abclinuxu]

Vlezl jsem do /var/cache/pacman/pkg a po zdlouhavém testování jsem přišel na to, že pacman -U nazev_baliku.pkg.tar.xz instaluje vybraný balík (soubor)

Jak dlouho že používáš Archlinux, když jsi toto zjistil až teď?

+1

[xm]

Žádný kernel panic, tohle je jen obyčejný oops, oprav si titulek blogpostu.

Nějaký ovladač (nebo jiný kernel-space proces) se pravděpodobně snaží přistupovat na adresu paměti kde nemá co dělat. Ale v _poskvrněném_ kernelu (proprietární NVidia ovladač) opravdu těžko říct a žádný jaderný vývojář se tím zabývat nebude.

Přístup co předvádíš mi osobně přijde naprosto otřesný, zaprvé zahoď proprietární ovladače, pak chybu zreprodukuj a nahlaš v bugzilla.kernel.org.

[Amarok]

Proc bych to hlasil na bugzille.kernel.org, kdyz zaroven pises, ze se tim zadny jaderny vyvojar zabyvat nebude? Nadpis jsem opravil, ale pojem "kernel panic" se ve vypisu prece objevil, jen jsem to neprocital do detailu. Proto jsem se i zminoval o tom, ze to zrejme opravdovy kernel panic ani neni, to by neslo dokoncit bootovani asi vubec.

[xm]

Nepochopil si, zabývat se tím nebudou dokud budeš mít kernel poskvrněný proprietárním ovladačem. Když chybu zreprodukuješ i bez něj, samozřejmě se tím zabývat budou.

Žádný "skoro panic", je to prostě kernel oops, tečka.

[Amarok]

OK, to stejne nastane, ted tam nvidii nemam a upgradovat budu tak jako tak, takze to pak poslu cele - pocitam ale, ze to bude uz v poradku (doufam), nvidii tam cpat uz stejne nebudu. Jak je to jinak s timhle vypisem chyb, jsou i v logu kompletne? Ze bych to uz nemusel fotit. Podivam se tam vecer.

[stativ]

Mělo by to být v dmesg a nejspíš i ve /var/log/kernel.log

[xm]

Oopsy jsou normálně v dmesg, takže bys je měl najít i v logu.

[Debianista]

Na archu "nepovedeny" upgrade? Nic nove... Klasika...

[Amarok]

Debian je ale druhy extrem, od nej jsem odesel kvuli naprosto zastaralym balikum, a to jsem ke konci pouzival testing a stejne mi to nevyhovovalo. Na server asi dobry, ale domu proste nic moc.

[Michal Fecko]

Osobne nemozem suhlasit - Debian Stable (Lenny v tomto case) prevadzkujem okrem cca 10 serverov a asi 2 desktopov na netbooku a musim povedat ze "starost" balikov ma nijako neobmedzuje - akurat starost krenela vyzadovala pre netbook rekompilaciu balikov na wifi a ethernet.

[Brusell]

Kamo, tobe asi nic nerika svata trojice Stable, Unstable a Testing ze???

[Marek Bernát]

Jak do toho zapadá Experimental?

[Jakub Lucký]

Ubuntu do toho netahej...

Ne vážně, experimental není kompletní verze, experimental nabízí jen některé balíky, zejména ty poprvé zařazované do repozitářů nebo zbrusu nové verze, aby se otestovalo, jestli tam není nějaká totální bota (ztráta dat apod.)... Aktuálně je tam něco pod 1900 balíků ( viz: wget http://packages.debian.org/experimental/allpackages?format=txt.gz -O- | gunzip | wc -l ) oproti 39 tisícům v unstable

[Marek Bernát]

Ok, len som sa pýtal, dík za info. Keď som kedysi používal debian, tak to bolo vždy testing alebo unstable, o experimental viem len toľko, že existuje

[Jakub Lucký]

Já na experimental víceméně jedu... Ale tak no je to takový víc adrenalinový sid

[stativ]

Tohle je kernel OOPS.

Přijde mi, že za to může snd_hda_intel. Nicméně zkusil bych dočasně zakázat načítání nvidiáckých ovladačů (abys neměl poskvrněný kernel) a zkusit nabootovat buď do konsole nebo grafiky (samozřejmě s nějakým jiným ovladačem) a pokud ten bug bude přítomný tak ho reportuj.

[stativ]

Nebo zkus pro začátek jen zakázat snd_hda_intel.

[Amarok]

OK, zkusim, dik. Kdyby mi sel vcera internet, tak jsem to uz mohl tady resit rovnou, ale byl jsem vubec rad, ze jsem to nejak rozbehl.

[Amarok]

Jinak jeste dotaz: na te prvni fotce v sekci "Modules", proc je tam za snd_hda_intel a za rt61pci to "(+)" a za nvidia "(P+)"? "P" bych tipoval na "proprietary", ale co to +?

[michich]

+ znamená, že modul se teprve inicializuje.

[alium]

http://www.abclinuxu.cz/zpravicky/x.org-server-1.9-rc3-vychazi-vstric-ovladacum-nvidia

[Amarok]

Bezva. Dalsi potvrzeni, ze by se to s upgradem nemelo prehanet, radsi nejaky ten tyden pockat, nez se vychytaji mouchy (hlavne teda u X, tam mi pripada ten zmatek asi nejvetsi).

[kotyz]

me to vsechno po tom upgradu normalne funguje a to mam taky binarni nvidii (nevim co si tomu proved, ze ti to udelalo tohle) ...

[stativ]

Já bych to neviděl ani tak na tu nvidii jako na jádro.

[kotyz]

jadro mam stejny.

[David Watzke]

+1, i používám snd_hda_intel

[vlastikroot]

Normální oops jádra. To nemá nic společnýho ani s archlinuxem, ani s jeho upgradováním. Se muže stát na jakymkoli distru.

[Amarok]

No s upgradovanim urcite jo, jinak by se mi to nestalo :) Ale zatim me tu teda vetsina presvedcila, ze na arch uz nenadavam, uznal jsem, ze to neni primo jeho vina, bude to proste i jen smula.

[Grunt]

Jak už bylo řečeno, tak to vypadá, že sletěl modul [snd_hda_intel] a podle názvu funkce to vypadá, že si ji ošahával. Takže dostat z toho příznak tained: P a pokud to bude furt dělat, tak někde nabídnout coredump a jméno balíku, který obsahuje ladící symboly. Rozhodně to není žádná katastrofa. Bych se měl asi pustit do sepsání nějakého toho článečku o základech ovládání gdb, ať se toho lidi tak nebojí, no škoda že na jádro jsem taková lama.

[Amarok]

Update: tak mi to nedalo, nemohl jsem cekat az na vikend a vse jsem na zaklade vasich prispevku vyzkousel. Doinstaloval jsem nouveau, dal jsem znova upgrade systemu, grafika uz ted beha jak po masle (teda vic nez desktop jsem nezkousel, ale predtim to bylo silene pomale). Ten kernel oops opravdu zpusobuje modul snd_hda_intel a nic vic, staci jen zakomentovat a vse OK. Traceback mam ulozeny, takze se pokusim ho poslat na tu jejich bugzillu, pokud to moc neni spojeno s byrokracii.

Ted jsem teda beze zvuku, z cehoz taky nemam radost, tak doufam, ze se to brzo spravi. Neni za ten snd_hda_intel mozno pouzit nejaky nahradni modul?

[Grunt]

Traceback mam ulozeny, takze se pokusim ho poslat na tu jejich bugzillu, pokud to moc neni spojeno s byrokracii.

Arch na to nemá nějaké automatické udělátka nebo mašinky?

Neni za ten snd_hda_intel mozno pouzit nejaky nahradni modul?

Třeba jako snd_hda_intel_fungující.ko?

[stativ]

Arch na to nemá nějaké automatické udělátka nebo mašinky?

Arch nemá žádná automatická udělátka. A proto ho mám rád.

[Amarok]

Tak na bugzille kernelu je ta chyba uz nekolikrat hlasena, a to dokonce ve spojeni se starsim kernelem. Tato hlaseni maji status NEW a Importance: P1 high, takze mi pripada zbytecne skoro to same hlasit taky??

[Ivanhoej]

a co sa stane ak ten modul natiahnes az po kompletnom nabootovani systemu ? Tiez padne ?

sudo modprobe snd_hda_intel

[Amarok]

Příloha:

• traceback2.txt (3554 bytů)

Stejny problem. Prikladam celkovy traceback problemu.

[Amarok]

Vyreseno! Sice blbe, ale funguje. Jelikoz je to znamy problem uz delsi dobu, tak jsem nasel plno patchu (zdrojaky C), do toho se mi vubec nechtelo, to riskovat nebudu a travit s tim cas se mi taky nechce. Nasel jsem ale informaci o moznosti pridat do GRUBu do menu.lst parametr pci=use_crs, coz se pry nedoporucuje, protoze to nektere systemy (hlavne se starsim BIOSem) muze rozhodit a cast hardwaru nemusi pak po bootovani fungovat. Me to nastesti funguje, zvuk uz taky bezi a nic zvlastniho pri bootovani jsem nepostrehl. Zkusim ten parametr za par mesicu odstranit.

[Ivanhoej]

tak to potom len pockat az ten modul opravia.

[kotyz]

to muze trvat hodne dlouho ...

[Woknař]

A teď si přesdstavte, že byste na tom systému kromě pokusů a bastlení taky museli normálně pracovat, jako my woknaři.

[vlastikroot]

A teď si představte, že byste na tom systému kromě hledání cracků na netu a klikání na next museli taky normálně pracovat, jako my linuxáci.

[Woknař]

Já cracky nehledám; nemám proč. Většina softu má - představ si - možnost aktivace hned po zakoupení. Anoooo, já vím, ten kradený Photoshop, to je mantra... ale zkuste už taky jinou; myslím, že už sami cítíte, že to není ono. Přesně takovouhle demagogií prohrál Paroubek všechno co mohl a přesně touhle demagogií si odeženete i zbytek těch, kteří by to jinak s Linuxem zkusili.

[vlastikroot]

Takže člověk používá open source stejně i na widlích, když tedy nechce dát za SW víc prachů než za HW (a ať mi nikdo netvrdí, že freeware muže být kvalitní). Pak teda neni co řešit.

[Woknař]

Ale jo, proč ne. Já jen že my opravdu neřešíme problémy - viz text blogu. Ono tak nějak - samo - funguje. A dobře.

[vlastikroot]

Ale tu jde zas o to, že archlinux je pro lidi, kterým tohle opravdu řešit nevadí. Pro lidi, co počítají s tím, že distributor je chytřejší než admin, to opravdu neni správná volba. Jsou i jiný distra, kde se člověk muže víceméně spolehnout, že se mu něco takovýho nestane.

[Amarok]

Ono tak nějak - samo - funguje. A dobře.

Diky! :D Aspon jsem se dnes vecer trosku zasmal, resim tedka tahani kabelu pres mistnost a po vycerpani jsem neco takoveho potreboval. Proc si jako myslis, ze jsme vsichni od Woken utekli? Abychom mohli resit problemy v Linuxu? A konec diskuze, na tohle vlakno uz nereaguju, opakovany vtip neni pak uz vtipem.

[kralyk z abclinuxu]

Ale jo, proč ne. Já jen že my opravdu neřešíme problémy - viz text blogu. Ono tak nějak - samo - funguje. A dobře.

[kralyk z abclinuxu]

přesně touhle demagogií si odeženete i zbytek těch, kteří by to jinak s Linuxem zkusili.

1. Cílem linuxu je poskytnout co možná kvalitní a efektivní systém, ne mít co nejvíce uživatelů (od toho je tu jiný OS)
2. Výkřik typu "windowsáci/linuxáci/whoever nemůžou na svém systému seriózně pracovat" má nulovou hodnotu
3. Zatažením politiky (zvláště Paroubka) do threadu se opravdu nic nezlepší, naopak

Jinými slovy jsi troll

[kotyz]

a trotl taky

[Chytrex]

Jinými slovy jsi troll

Ale dyť o on ví celou dobu.. On tady s tím přišel:D

[kotyz]

Příloha:

• invalid_argument.jpg (85291 bytů)

mluv s rukou, protoze moje hlava takovy kecy posloucgat nebude ...

[xm]

A teď si představ, že na Arch Linuxu normálně v práci i doma už několik let pracuji.

[Chytrex]

to ti neuvěří... Jiný systém než to Billovo dílo zkázy přece nemůže tak nějak - samo - fungovat.. BTW i doma i v práci mám debian Lenny. A zatím jsem neměl problém s ničím;)

[Václav "Darm" Novák]

Potlesk. Srovnávat nerd-friendly Arch určený pro opravdu zkušené uživatele který v podstatě nemá žádnou fixně stabilní verzi s Windows je opravdu příspěvek hodný megatrolla. Děkuji. Mimochodem, osobně bez větších trablí používám stejnou instalaci Archu od roku 2004, za tu dobu bez reinstallu prodělal celý systém postupný upgrade technologicky srovnatelný s přechodem Win XP -> Vista -> Windows 7, postupně přežil můj starý počítač, jeho opravu po smrti desky a následný přesun disku na mou aktuální sestavu.

Nechci pořád přeinstalovávat, chci normálně pracovat a jeden nepovedený update za dva roky s opravou 5 min. google a 5 min. práce s kompletním reinstallem oken neporovnáš :)

[pozortucnak]

Tak když už je tu diskuze o tom proč používat či nepoužívat Arch linux, tak třeba já používám Arch linux hlavně proto, že má AUR. Možná že třeba takové Ubuntu je více user friendly, ale když BFU narazí na program, co není v repositáří, tak je v háji. Kompilace je peklo, protože je třeba instalovat dev balíky snad poloviny všech balíků. Utility typu auto-apt nejsou řešením.

A také si myslím, že to přispívá k malé popularitě linuxu. BFU je odkázaný na programy v repozitáři a to je chyba!!

Zkuste svojí maminku/babičku naučit kompilaci programů...

[Grunt]

Zkuste svojí maminku/babičku naučit kompilaci programů...

Toto jsen nikdy nepobral. Co je na tom? Jen si pořádně přečíst README, stáhnout všechny potřebné závislosti a vyťukat tři příkazy. V takovém Gentoo je to plně automatizované a ještě na to existuje grafický nástroj Kuroo (možná existuje i něco pod GTK), kde stačí požadované balíky pěkně klikáním pooznačovat, kliknout na obří tlačítko Compile! a jít na kafé (a neb se vrhnout do práce, pokud to někomu nevadí). Že to nezvládne dnes maminka/babička kvůli tomu jak se to dělá neznamená, že kompilace je složitá. Znamená to jen, že chybí nějaký jednodušší nástroj pro maminku/babičku. Jinak je to úplně stejné jako instalace jakéhokoliv binárního balíku, jen s tím, že instalace bin. balíků je plně automatizovaná. Toť vše

[Amarok]

IMHO opomijis jednu vec:

stáhnout všechny potřebné závislosti

Prave zavislosti muzou byt fakt peklo (zazil jsem kdysi v SuSE, od te doby kompiluju jen vyjimecne z AUR, kde je to v pohode). Jakmile to uz vesele kompiluje, tak je skoro vyhrano.

[Grunt]

Znovu je to jen věcí automatizace. Ze zkušenosti vím, že valná většina závislostí se nachází už i v základním repu v podobě -dev balíčků. Jen zatím není standardizovaný žádný způsob jak všechny závislosti stáhnout jednou ranou bez ručního hledání (teda krom Gentoo samozřejmě).

[Begleiter]

Kompilace je peklo, protože je třeba instalovat dev balíky snad poloviny všech balíků.

Možná budu vypadat jako blbec, ale... Já pořád mám za to, že AUR je jakousi databází skriptů, které automatizovaně vytvoří požadovaný balíček. A i ten skript pro tvorbu balíčku potřebuje (pokud kompiluje) dev balíky.

[Grunt]

Kompilace je peklo, protože je třeba instalovat dev balíky snad poloviny všech balíků.

? V případě, že by se všechny automaticky nainstalovaly a po instalaci zas třeba všechny automaticky smazaly, tak nechápu v čem je problém.

[Begleiter]

man makepkg říká:

-r, --rmdeps
           Upon successful build, remove any dependencies installed by makepkg
           during dependency auto-resolution and installation when using -s.
-s, --syncdeps
           Install missing dependencies using pacman. When build-time or
           run-time dependencies are not found, pacman will try to resolve
           them. If successful, the missing packages will be downloaded and
           installed.

[Václav "Darm" Novák]

yogurt navíc dokáže dotahat závislosti i z AUR.

[Begleiter]

Vyzkouším.

[pozortucnak]

Máte pravdu. Ale tady jde o to, že Arch linux není pro BFU, jak ostatně dokazuje i tento blog. Pro BFU je Ubuntu nebo openSuse a v nich nic jako AUR není...

[Begleiter]

Arch Linux se drží koncepce "udělej si sám". Což mi vyhovuje.

[kralyk z abclinuxu]

No ono těch "dev" balíků v Archu je potřeba obvykle minimum (v porovnání s Ubuntu), nehledě na to, že afaik se balíky v Archu nedělí na dev a ne-dev čili maximálně si to řekne o nějaký konkrétní nástroje/knihovny, a to není problém...

[xm]

Distribuce, co dělí balíky na normální a -dev jsem vždycky nesnášel. Na serverech sice používám Debian, ale neskutečně mě to irituje. Na desktop bych si nikdy takovou distribuci nedal.

[Grunt]

Proč? Mně naopak rozdělení na binárky nutné k provozu, -dev a -dbg balíky přijde geniální.

[Marek Bernát]

Ty budeš mať asi dosť nízke požiadavky na genialitu

[Grunt]

Proč? Napadá snad někoho jak to udělat líp?

[Marek Bernát]

Líp? A podľa akého kritéria budeš radiť moje návrhy?

[Grunt]

Dobře: A napadá někoho jak to udělat jinak?

[Marek Bernát]

Samozrejme, baliť tie veci spolu

[Grunt]

No tak to bude výhra.

[Marek Bernát]

Žiadna výhra to nie je. Len jedna z možností. Ale že by bolo oddeľovanie zdrojákov do -dev balíčkov, ktoré majú veľkosť nula nula nič a treba ich explicitne inštalovať geniálne... to sa asi tiež zrovna nedá povedať, čo?

[Grunt]

No kdyby k tomu existoval nějaký systém, tak aby je člověk nemusel instalovat ručně?

[Marek Bernát]

Myslíš niečo ako, že spustíš configure a on si sám zistí, ktoré balíky treba stiahnuť? To by ešte šlo. Ale oveľa jednoduchšie je -dev proste pribaliť k normálnym balíkom.

[xm]

Protože když si nainstaluji aplikaci, chci jí mít komplet, tzn. včetně všech headerů, atp. Dělení na -dev balíčky jednoduše považuji za neskutečný opruz (situace s -dbg je poněkud jiná, jelikož debug symboly brzdí běh aplikace).

[Grunt]

situace s -dbg je poněkud jiná, jelikož debug symboly brzdí běh aplikac

Nebrzdí. Jen žerou víc místa na disku a při stahování. Úplně stejně jako hlavičkové soubory (jen v menší míře). Takže nač si zacpávat prostor, když je pro mě kompilace sprosté slovo?

[xm]

Chceš mi říct, že debug symboly nemusí zabírat místo v paměti a zpomalovat start (a možná i běh) aplikací? Moje osobní zkušenost je tedy jiná (debug symboly opravdu brzdí a to dost drasticky), ale jestli existuje způsob jak používat debug symboly bez těchto negativních dopadů, moc rád se poučím! Pak bych samozřejmě byl proto, aby i debug symboly byly ve standardních balíčcích zahrnuty.

Nicméně nemyslím si, že by debug symboly zabíraly méně místa než hlavičkové soubory. Minimálně u takového KDE (a předpokládám i jiných složitějších C++ aplikací) jsou debug symboly (na rozdíl od hlavičkových souborů) děsivě velké (dohromady stovky megabajt či možná i více).

[Grunt]

Chceš mi říct, že debug symboly nemusí zabírat místo v paměti a zpomalovat start (a možná i běh) aplikací?

Ne. Jsou totiž v separovaných souborech a s původní aplikací nemají nic společného. Jen když se debuguje, tak si je gdb tahá a překládá pomocí nich všechny ty číslice (adresy, …) do člověku srozumitelné formy. Více viz. info gdb sekce GDB Files.

Nicméně nemyslím si, že by debug symboly zabíraly méně místa než hlavičkové soubory. Minimálně u takového KDE (a předpokládám i jiných složitějších C++ aplikací) jsou debug symboly (na rozdíl od hlavičkových souborů) děsivě velké (dohromady stovky megabajt či možná i více).

Však takto jsem to také myslel.

[Marek Bernát]

Takže rozumiem tomu správne, že pod linuxom neexistuje niečo ako debug/release verzia binárky? Lebo vo Visual Studiu sa medzi tým dalo prepínať a tá debug verzia bola výrazne pomalšia (aj keď si nedebugoval). Pod linuxom sa debug symboly teda týkajú len gdb a nespôsobujú žiadne spomalenie?

[xm]

Existuje, sám jsem to tak používal když jsem potřeboval debugovat nějakou aplikaci (rekompiloval jsem jí se zákazem stripování debug symbolů v PKGBUILDu). Ale zjevně to jde i jinak (lépe), o té jiné možnosti jsem však až doteď nevěděl, člověk se pořád učí novým věcem

[Grunt]

Nemám páru jak se to dělá ve Visual studiu, ale ELFy na to mají své sekce kde drží debugovací symboly. Ty jsou drženy odděleně od kódu (nemixují se mezi kód), takže k separaci do samostatného souboru je to už jen krůček. Samozřejmě, gcc se switchem -g vygeneruje jednu binárku ve které je to všechno. Viz info gdb a sekce Symbols (ale abych pravdu přiznal, tak daleko jsem se ještě nedostal, takže si to jen myslím na základě zkušeností práce s objdumpem).

Pod linuxom sa debug symboly teda týkajú len gdb

Samozřejmě, že ne. Může je využívat i libovolný jiný program a pro samotné symboly existuje formátů několik, snad ještě z dob Unixů. Vše popsáno někde v info gdb.

nespôsobujú žiadne spomalenie?

Nebudu lhát. Nezkoumal jsem to. Ale vzhledem k tomu, že leží naprosto mimo strom a krom nějakého debugovacího nástroje není kdo je do paměti nahrál (dynamický loader to nedělá určitě), tak mě nenapadá jediný logický důvod proč by měly.

[Grunt]

Jinak teď se chystám debugovat jádro na jednom bordu skrze RS232. To se dělá tak, že se tam nahraje normální ostripovaná verze jádra bez jediného debugovacího symbolu (neostripovaná verze by se tam i tak nevešla), na druhé straně se spustí gdb kde jako obraz slouží vmlinux právě s debugovacímy symboly a kgdb jen posílá z boardu gdbčku na ovládacím stroji skrze RS232 jen adresy a nějakou binární hatlamatilku z paměti a gdb to právě pomocí symbolů jen překládá a zas posílá zpět kgdb adresy třeba breakpointů nebo watchpointů. No a pokud pominu nějaké krokování tak to ostripované jádro IMHO na tom boardu běží stejně rychle, jestli na ten RS232 připojený jsem nebo ne (už jen z toho důvodu, že je to jádro jako každé jiné a o nějaké speciální volbě která by to razantně zrychlila a přitom znemožnila debugování ani stejně nevím).

[Marek Bernát]

Aha, dík, to som nevedel.

Jasné, nešlo mi konkrétne o gdb, ale či sú tie debug symboly mimo normálny beh programu (tak ako si to popísal v prvom odseku).

Podľa toho, čo si povedal, mi to tiež tak pripadá. A niekto to už určite testoval. Stačí pogoogliť

[Grunt]

Lebo vo Visual Studiu sa medzi tým dalo prepínať a tá debug verzia bola výrazne pomalšia

Možná to bude jen způsobeno tím, že MSVS je zas nástroj chytřejší než samotný programátor. V GNU jsou při klasickém překládání zapnuty optimalizace na druhou úroveň (-O2) a to se dá kombinovat i s ladícími symboly (-g), jen to má za následek to, že čas od času je některá proměnná tzv. vyoptimalizovaná ven (value optimized out) když se na ni chce zrovna podívat + možná ještě nějaké chování o kterém nevím. Když se na tu proměnou chce člověk podívat i tak, musí to přeložit s nižší úrovní optimalizace a nebo optimalizace úplně vypnout (-O0). A možná jen při zapnutí debugovaní automaticky MSVS také automaticky vypne optimalizace a vyleze z toho neoptimalizovaná binárka, která je pomalá i když se zrovna neladí.

[Marek Bernát]

To je dosť možné. Ale ten istý problém by mal byť teda aj pod linuxom, nie? Keď chceš mať skutočne plnohodnotné debug informácie, tak musíš vypnúť optimalizácie. Ergo debug binárka bude pomalšia.

[Grunt]

Nemusíš. Za dobu co debuguju se mi pakrát stalo, že hodnotu, kterou jsem chtěl sledovat jsem neměl, ale jinak je to k ničemu (samozřejmě nepočítám případ, kdy optimalizace mění sémantiku kódu, jako jsme tu měli nedávno – ale v takovém případě jsou debugovací symboly stejně na nic). Otázkou je jak se to ale potom řeší v případě binárních dister a repositářů. Nesou si ty -dbg balíčky i nějaké informace o vyházených hodnotách (ekvivalent úrovně -O0) a nebo má prostě člověk smůlu a musí si něco takového přeložit sám? To už nevím.

[kralyk z abclinuxu]

Headry (narozdíl od debug symbols) prakticky žádné místo nezaberou. Není důvod je oddělovat...

[Grunt]

Lhát nebudu. Proč se to odděluje? Netuším. Ale asi k tomu nějaký logický důvod bude, když se to dělá. Min. mě nenadá jediný důvod k čemu by hlavičkové soubory na disku byly, když se jen instaluje, spouští, maže a nic nekompiluje. Samotné hlavičkové jsou jen API mezi programy a knihovnami, které překladač využije když je potřebuje na sebe vařit, ale jakmile se přeloží do binární podoby, tak jsou tam vlastně dvakrát. Jednou v podobě binární v knihovnách a souborech (to je potřebné) a podruhé v podobě zdrojové (což je samo o sobě bez překladu na nic). Takže nač je držet?

[Marek Bernát]

A jak si dospel k tomu, že nikto nepotrebuje nič kompilovať (aspoň mám pocit, že si k tomu dospel)? Aj keď vynecháme programátorov, tak stále je kopa ľudí, ktorí si potrebujú čas od času niečo skompilovať ručne (občas to inak nejde). A vtedy musia explicitne inštalovať 100 balíkov, ktorých veľkosť je prakticky nulová. Fakt výhra...

[Grunt]

S tím na mě prosimtě nechoď, jo? Já už tu nějaký pátek proklamuju, že základní stavební jednotkou GNU není binární executable, ale zdrojový kód. To se jen na mě vždy slétne pár supů/lam co mají očividně jiný názor a ten můj považují za nebezpečný. Pár souborů navíc v /include a /usr/include by jim asi způsobilo nesnesitelné bolesti hlavy nebo já nevím. Mě se na to neptej.

A jak si dospel k tomu, že nikto nepotrebuje nič kompilovať (aspoň mám pocit, že si k tomu dospel)?

Ale kdybych už měl racionálně argumentovat, tak bych začal s tím bazmekem co začal distra dělit na binární (Debian,…) a zdrojové (Gentoo,…). V binárním distru jsou prostě hlavičkové soubory na nic pokud člověk nechce výslovně buildit.

[Marek Bernát]

Priznám sa, že ti prestávam rozumieť. Nebol si to ty, kto povedal, že oddelenie -dev balíkov je geniálne? Alebo to mal byť sarkazmus?

No, ak sú pre to binárne distro k dispozícii balíky pre úplne každú aplikáciu s úplne každou možnou kombináciou kompilačných nastavení, tak tiež nevidím dôvod mať tam zdrojové súbory...

[Grunt]

Priznám sa, že ti prestávam rozumieť. Nebol si to ty, kto povedal, že oddelenie -dev balíkov je geniálne? Alebo to mal byť sarkazmus?

Ne, sarkasmus to nebyl. Myslel jsem to vážně. Ještě jsem zapomněl do výčtu přidat *-source. Ale je to způsobeno hlavně tím, že dnešní distra jsou orientovaný příliš binárně (v takovém případě je to dělení geniální). Kdyby tomu tak nebylo, tak už bych to možná za tak geniální nepovažoval.

No, ak sú pre to binárne distro k dispozícii balíky pre úplne každú aplikáciu s úplne každou možnou kombináciou kompilačných nastavení, tak tiež nevidím dôvod mať tam zdrojové súbory...

Což je jeden z důvodů proč jsem pro zdrojové balíčky místo těch binárních všemi deseti.

[Grunt]

A *-doc jsem ještě zapomněl.

[Marek Bernát]

Aha, tak aj ja sa opravím Delenie na -source/-doc/-debug mi tiež pripadá celkom rozumné, lebo obvykle to človek nechce a zaberá to dosť miesta. Ale -dev mi tam pripadá zbytočné, lebo väčšina ľudí to skôr čí neskôr využije a moc miesta to nezaberá.

[Grunt]

lebo väčšina ľudí to skôr čí neskôr využije a moc miesta to nezaberá.

proof needed + čistě subjektivní názor.

[kralyk z abclinuxu]

proof needed

Níže to máš. Veškeré headry u mně (a že tam toho mám nataháno dost) zabírají trapných 271MB

[Grunt]

Však počkej zajíci králíku. Já ten příkaz, který mi zobrazí velikost všech -dev balíků k balíkům co už mám nainstalované jednou najdu.

[kralyk z abclinuxu]

Když má člověk k ruce ABS, tak -source tak nějak nemá imho smysl...

[Marek Bernát]

ABS je analóg k source balíkom v debiane (aj keď premakanejší). Na druhej strane, existujú v archi -doc a -debug balíky? Doteraz som to nikdy nepotreboval, tak vlastne ani neviem

[kralyk z abclinuxu]

Znám snad jen qt-doc, takže taknějak předpokládám i existenci dalších. Ale ruku do ohně za to nedám

[stativ]

Tím moc místa to nezabírá bych si nebyl tak jistý. Kvůli tomu je nově v archu odděleno boost-libs (knihovny) a boost (devel věci). Knihovny mají totiž 18 MB a devel věci mají 112 MB. Ale tohle je asi extrém (další takovou věcí je asi jen jádro a gcc)

[Marek Bernát]

First of all, to je dosť špeciálny prípad. Second of all, čo všetko v tom booste je? 100MB devel vecí mi pripadá neskutočne veľa. Určite to nemôžu byť len hlavičkové súbory

[stativ]

First of all, to je dosť špeciálny prípad.

Když vy jste se tu tak hezky hádali. Prostě jsem si musel aspoň trošičku rýpnout.

Second of all, čo všetko v tom booste je? 100MB devel vecí mi pripadá neskutočne veľa. Určite to nemôžu byť len hlavičkové súbory

Máš pravdu, nejsou to jen hlavičkové soubory .

Hlavičkové soubory:

[lukas@orochi ~]$ pacman -Ql boost | grep "/usr/include" | wc -l
7888

Ostatní věci (konkrétně nějaké moduly pro Python):

[lukas@orochi ~]$ pacman -Ql boost | grep -v "/usr/include" | wc -l
101

[stativ]

Ostatní věci (konkrétně nějaké moduly pro Python):

[lukas@orochi ~]$ pacman -Ql boost | grep -v "/usr/include" | wc -l
101

A statické knihovny. Ty mají 46 MB.

[kralyk z abclinuxu]

$> du -hs /usr/include/boost/
65M     /usr/include/boost/

Ono když se člověk podívá do dokumentace boost (tady), tak tam píšou, cituji:

Most Boost libraries are header-only: they consist entirely of header files containing templates and inline functions, and require no separately-compiled library binaries or special treatment when linking.

Čili de-facto většina zdrojáků boostu je v *.hpp, takže není divu, že maj 65MB.

[stativ]

Vvšak je tam spousta šablon a ty do knihovny nenacpeš. Tedy pokud máš kompilátor, který podporuje export šablon tak to tam nacpeš, ale vzhledem k tomu, že export AFAIK nepodporuje ani jeden z velkých hráčů (GCC, MSVC, Intel) tak se to prakticky nepoužívá.

[Marek Bernát]

No ja neviem, ja na tom nič geniálne nevidím.

Čo ja viem. Binárne balíčky sú fajn v tom, že nemusíš nič kompilovať a obvykle to funguje. Na druhej strane, gentoo USE_FLAGy by som občas bral. Ale človek nemôže mať oboje, sú to dva oddelené svety. A keď si mám vybrať len jeden, tak asi ten binárny a tých pár programov, pre ktoré mi nevyhovujú binárne balíky, si už nejak skompilujem ručne.

[Grunt]

Ale človek nemôže mať oboje^{[citation needed]}

vs

A keď si mám vybrať len jeden, tak asi ten binárny a tých pár programov, pre ktoré mi nevyhovujú binárne balíky, si už nejak skompilujem

[Marek Bernát]

Asi som sa zle vyjadril. Išlo mi len o to, že nevidím žiadny zmysel v mixed systéme, kde polku nainštalovaných balíkov budú tvoriť zdrojové a polku binárne. AFAIK všetky distrá sa delia na binárne a zdrojové a obvykle nainštalovaných a skompilovaných zdrojových balíkov v tom binárnom je len pár. To isté platí pre binárne balíky v zdrojovom distre.

[Grunt]

Išlo mi len o to, že nevidím žiadny zmysel v mixed systéme, kde polku nainštalovaných balíkov budú tvoriť zdrojové a polku binárne.

Presne v takom systéme zmysel vidím. A to docela podstatný.

[Marek Bernát]

Nič proti; 100 ľudí, 100 chutí. Len som vyjadril svoj názor + skúsenosť s tým, že som ešte nič podobné nevidel. Jaký zmysel v tom teda ty vidíš?

[Grunt]

Len som vyjadril svoj názor

Jasně, proti tomu nic. Já tě jen slušně upozorňuju, že je to špatný názor.

skúsenosť s tým, že som ešte nič podobné nevidel

Jsme dva.

aký zmysel v tom teda ty vidíš?

Jak už jsem řekl. Zdrojové kódy/balíky jsou základním stavebním kamenem GNU (MHO). Vyjmenovávat všechny výhody tady asi nemá cenu. A zatím největší překážka jejich nasazení je složitost. Resp. ono to není složité, ale je pravda, že mojí babičce bych to asi fakt nenutil. Je to jen potřeba dostat do takového stádia aby ani pro ni nebyl problém stáhnout si nějaký _tar.gz_ dvakrát kliknout, nastavit co potřebuje a nainstalovat. No na druhou stranu, kompilovat celý systém od základu asi moc nemá smysl už jen z toho důvodu, že v 90% případů by to všechno skončilo na identických binárkách. Proto tedy binární systém jako základ + možnost jakýkoliv libovolný free software si dokompilovat. V tom smysl vidím.

[Marek Bernát]

Podľa mňa nie je nesprávny, vzhľadom k tomu, čo hovoríš vo zvyšku komentára

To čo tu popisuješ ale predsa nie je nič iné, než binárne distro s možnosťou kompilovať zopár koncových (e.g. nesystémových typu libc) zo zdrojákov. To máš už dnes v každom distre. Tak čo je vlastne ten tvoj super systém s 50% balíkov binárnych a 50% kompilovaných? Žiadny rozumný príklad použitia si neukázal. Naopak, dostali sme sa k tomu, že môj názor je správny a len ty nevieš, čo vlastne chceš Ono je to totiž skutočne v tom, že ako zdrojáky, tak binárky ti ponúkajú najväčšie výhody, keď ich používaš takmer výhradne. V okamihu, keď to začneš miešať, tak kopu výhod strácaš.

[Grunt]

V okamihu, keď to začneš miešať, tak kopu výhod strácaš.

Např.?

[Marek Bernát]

No, tak je asi zrejmé, že keď máš ľubovoľné nezanedbateľné množstvo binárnych balíkov, tak si stratil výhodu USE_FLAGov, lebo keď budeš chcieť niečo zmeniť, tak tak či tak budeš musieť tie binárne balíky vyhodiť a celý systém prekompilovať. Čiže sa dostaneš do stavu zdrojovej distribúcie. Naopak, ak máš nezanedbateľné množstvo balíkov zo zdrojákov, tak si stratil možnosť pohodlne updateovať systém bez toho, aby si ho celý rekompiloval (obrovská to výhoda binárnych distribúcií). Musíš si holt vybrať. Pohodlnosť, alebo konfigurovateľnosť. Alebo ani jedno

[Grunt]

No, tak je asi zrejmé, že keď máš ľubovoľné nezanedbateľné množstvo binárnych balíkov, tak si stratil výhodu USE_FLAGov, lebo keď budeš chcieť niečo zmeniť, tak tak či tak budeš musieť tie binárne balíky vyhodiť a celý systém prekompilovať.

Nevím jak koho, ale mě nastavování USE_FLAGů každého balíku po chvíli pěkně omrzelo. Naopak jsem to využil jen u několika. A nechápu proč by si kvůli jednomu USE_FLAGu musel překompilovat celý systém. U balíku u kterého si to nastavíš je jasné, že se to překompilovat bude muset, ale nikdo neříká, že ty závislosti budou zase muset být zdrojové. Zvolíš si nějaký USE_FLAG, natáhnout se ti požadované binární knihovny + závislosti a hotovo. Navíc dost pochybuju, že USE_FLAGy by tak moc zajímaly moji babičku. Té by bohatě stačil i default. Ale když chceš překompilovávat celý systém ala Gentoo, nevím proč by ti měl někdo bránit.

Naopak, ak máš nezanedbateľné množstvo balíkov zo zdrojákov, tak si stratil možnosť pohodlne updateovať systém bez toho, aby si ho celý rekompiloval

Co? To zas proč? Jaký je rozdíl v balíku v případě, že ho zkompiloval maintainer a nebo ty? IMHO je to úplně jedno jestli je nainstalovaná knihovna libogg-1.1.4.i686 nebo libogg-1.1.4.src, prostě když bude dostupná libogg-1.2.3.i686(nebo libogg-1.2.3.src), měla by se ti nabídnout. Stejně tak je jedno jestli ta knihovna byla nainstalovaná z repositáře nebo z externího zdroje (a to platí v binárních distrech už dnes). Prostě když je dostupná vyšší verze balíku s nějakým názvem (ať je to i686, x86_64 nebo src) měla by být nabídnuta i případě, že by to znamenalo přepsání výsledku několika hodin kompilace.

[Marek Bernát]

Mimo USE_FLAGy nevidím veľký zmysel v distribúciách založených na zdrojových balíkoch. Vysvetlíš mi, načo si teda budeš 50% balíkov v systéme kompilovať, keď dostaneš znova len to isté, čo ti ponúkal binárny balík? Zrejme chceš dosiahnuť niečo, čo ti pôvodný systém neponúkal.

Rozdiel je tam veľký, stačí keď si uvedomíš, že binárny balík je de facto len jeden (ten z oficiálneho repa). To je centrálne riadený systém so všetkými výhodami. Kompilovaných balíkov je ale možno spraviť hocikoľko pre daný program. To je tvoja lokálna verzia. Je nad slnko jasnejšie, že nemôžeš rozumne skombinovať centrálne a lokálne riadené updaty. Tie lokálne updaty budú vždy potrebovať prekompilovať všetky dotknuté balíky (v opačnom prípade hrozí, že niečo prestane fungovať). Druhá možnosť je prepísať lokálnu verziu centrálnou. Lenže tým prichádzaš o všetky lokálne zmeny a si tam, kde si bol na začiatku: v binárnom distre...

Proste nechápem, čo chceš. Ešte si mi nedal ani jeden príklad použitia, kedy by malo zmysel výrazne miešať zdrojové a binárne balíky (v zmysle polovica takých a polovica takých). Čo ti napríklad neumožňuje debian alebo arch, čo by si bol schopný robiť v tom tvojom mixed-distre?

[kralyk z abclinuxu]

$> du -hs /usr/include/
271M    /usr/include/
$> find /usr/include/ | wc -l
30578

Takže mě přítomnost headrů opravdu netrápí