Jaderné noviny – 20. 1. 2010 (diskuse)

[Radek Podgorny]

Diky moc za tenhle serial!

...ale, jsem exot, kdyz mi pripada preklad typu "usondy" uz trochu moc?

[Nikola Ciprich]

nejste, taky mi to prijde hrozne... ale nejde se vzdycky zavdecit vsem, a vetsina lidi zrejme preferuje prekladat vsechno co nejvice.. :( takze se my anglofilove musime podridit :)

[ewqrqwr]

hlavni je informacni hodnota, i kdyz je fakt, ze u_sondy zni jak nazev pajzlu.

[Filip Jirsák]

Mně se ten překlad naopak líbí, myslím si, že přesně takhle by měl překlad vypadat.

[Michal2]

Myslis tak, aby si to clovek musel prelozit zpet aby pochopil o cem je rec? Kdo to nedokaze tak je v haji uplne. Chce vedet vic, napise do googlu usondy a najde prd.

[Filip Jirsák]

Právě naopak – člověk si to nemusí překládat zpátky, nemusí dokonce zdrojovému jazyku vůbec rozumět, a přesto pochopí, o čem je řeč. Je to překlad, který plnohodnotně nahrazuje originál a čtenář, který rozumí česky, se z něj dozví totéž, co se dozví z originálu anglicky mluvící.

Když zadá někdo do Googlu „usondy“ a nenajde nic, znamená to asi, že o nich nic v češtině není. Pokud chce hledat články v angličtině, nevím, proč čte české Jaderné noviny a ne anglický originál.

[neaktivni]

a co jsou to teda usondy?

[Filip Jirsák]

Vlastnost pro řešení dynamického sledování aplikací v uživatelském prostoru. Máte to napsané v článku. Jinak, jak je z názvu patrné, jsou to určité druhy sond.

[Libor Chocholaty]

Problem nastal v dalsim clanku, kdy autor slovo "usondy" zacal skonovat. Kdyz vidim "usond" patram v pameti po nejakem daemonu, ktery se tak jmenuje. Ze jde o uprobes me ani nenapadlo. A ze by se melo jednat o nejake sondy taky ne.

[Ondrej 'SanTiago' Zajicek]

Pokud chce hledat články v angličtině, nevím, proč čte české Jaderné noviny a ne anglický originál.

Treba proto, ze si radsi precte clanek v cestine, ale kdyz dalsi dokumentace v cestine neni, tak se spokoji s anglickou dokumentaci.

[Filip Jirsák]

Pokud chce hledat anglickou dokumentaci, tak ať hledá anglický termín (v článku jej má napsaný také). Hledat anglickou dokumentaci s použitím českého termínu je poněkud hloupé.

[Robert Krátký]

aby si to clovek musel prelozit zpet aby pochopil o cem je rec

V článku je uveden i původní termín.

[mikro]

Pochopil niekto, ako sa to myslelo s tymi 32-bit vs 64-bit jadrami tam na zaciatku? Pozrel som anglicky original, precital viac krat po sebe ten cesky preklad, ale stale nechapem, co bola vlastne pointa.

[petr_p]

Že kdokoliv, kdo má více jak 1 GB, má použít 64b jádro.

[petr_p]

Na druhou stranu pán asi žije v jiném světě. U nás se běžně do 32b strojů dokupuje paměť.

[Pavel Francírek]

Ona signatura "H. Peter Anvin, Intel Open Source Technology Center" o něčem vypovídá :) Podle Intelu už asi mají dávno být všude nové 64bit procesory.

[stativ]

No, jak já to chápu, tak tím myslí následující. Pokud máš teď ve svém PC více než 1GB paměti, ale kvůli nějaké pitomosti (třeba nějaký program, úchylka uživatele na 32bit userland) musíš provozovat 32bit systém, tak musíš mít jádro s podporou HIGHMEM, což je, jestli se nepletu ne zrovna efektivní. Co autor doporučuje, je mít 64bit jádro a vše ostatní mít 32bit. Bohužel to žádná současná distribuce neumožňuje (buď máš komplet 32bit systém nebo 64bit systém, do kterého si můžeš nainstalovat vybrané 32bitové balíčky)

[trekker.dk]

Bohužel to žádná současná distribuce neumožňuje

Slyšel jsi někdy o Debianu?

[stativ]

Překládal jsem jen, jak jsem to pochopil. U Debianu v tom nevidím nějaký zvláštní problém. Sice jsem tuhle kombinaci ještě neviděl, ale když tam člověk může mít jako jádro Hurd tak by bylo divný, kdyby to nešlo. Gentoo a SourceMage to samé. A samozřejmě LFS

[trekker.dk]

Překládal jsem jen, jak jsem to pochopil.

Jo tak. Ona ta stížnost nebyla, že to distribuce nepodporují, ale spíš že taková možnost není dostatečně propagována.

[Jiří J.]

Je tam Dokonce v defaultním i386 repozitáři.

Původně jsem si to tak chtěl nechat, mám tu docela dost binárních 32bit aplikací (bez dostupného zdrojáku) a štvát se s nějakým transparentním chrootem se mi nechtělo. Pak mé oko našlo něco jako lib32 v amd64 verzi repozitáře a už jedu vesele na 64bit .

[Václav Kramář]

vaclav@debian:~$ uname -a
Linux debian 2.6.30-bpo.1-amd64 #1 SMP Mon Aug 17 19:58:33 UTC 2009 x86_64 GNU/Linux
vaclav@debian:~$ file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.8, stripped
vaclav@debian:~$

http://packages.debian.org/stable/linux-image-amd64

[Kaacz]

hmm, tak tohle si musim nekde vygooglit ... protoze vsude se vzdy tvrdilo ze 32bit primo adresuje 4GB .. coz pravda je .. tak k cemu HIGHMEM ?!?!?!

mozne je ze jinak to dela i386 a jinak i686. Mel jsem pocit, ze kdyz mam kernel i586/i686, tak 2-3GB adresuje primo a nepotrebuje zadne berlicky. U plneho vyuziti 4GB uz by clovek potreboval PAE a tam je samozrejme lepsi jit do 64bit.

Ale napr. na iAtom330+ION media center s 2GB RAM pro prehravani HD filmu nevidim jediny duvod jit do 64bit. Vykonove nic neziskam, instalace je vetsi, binarky jsou malinko vetsi, nektere si zaberou vic pameti .. proste zbytecne.

Nemluve o tom, ze XBMC autori neustale pindaji ze to ladi jen na 32bit a 64bit je nezajima ..

Tak ted babo rad.

[stativ]

hmm, tak tohle si musim nekde vygooglit ... protoze vsude se vzdy tvrdilo ze 32bit primo adresuje 4GB .. coz pravda je .. tak k cemu HIGHMEM ?!?!?!

Proč to tak je nevím, ale můžu potvrdit, že 1,5 GB RAM mi bez HIGMEM na 32bitu neběhá.

[trekker.dk]

AFAIK to souvisí s dělením adresového prostoru mezi jádro a uživatelský prostor.

[Jakub Lucký]

# aptitude show linux-image-2.6.32-2-686-bigmem 
Package: linux-image-2.6.32-2-686-bigmem
Version: 2.6.32-8
Provides: linux-image, linux-image-2.6, linux-modules-2.6.32-2-686-bigmem
Description: Linux 2.6.32 for PCs with 4GB+ RAM
 The Linux kernel 2.6.32 and modules for use on PCs with 4-64GB RAM, using PAE (Physical Address Extension). 

A na mém stroji 32bitový kernel (64bitový má/měl rozbitý ioctl wrapper (nefungoval třeba wpa supplicant)) zvládá 2GB RAM bez problémů (Opera mi je občas zdatně zaplní)

[Filip Jirsák]

V části o souborových systémech je za větou Ted hovořil s veterány vývoje souborových systémů posledních let odkaz bez textu (který se projevuje jen šipečkou). Předpokládám, že jeho utajení nebyl záměr…

[trekker.dk]

Textem toho odkazu je ten obrázek vedle, ta šipka je v místě, kde je v HTML ten odkaz. Je to udělané stejně jako na LWN, jenže tam to jednak nevede mimo a druhak nemají tyhle praštěný šipky.

[Filip Jirsák]

V tom případě by se tomu odkazu měla přidat třída noext, která tu šipečku odstraní.

[trekker.dk]

Napiš, jak ten odkaz má vypadat, já to tam klidně budu dávat (ale tady to už změnit nemůžu)

[Filip Jirsák]

V tomto případě by to mělo být: <a class="noext" href="http://lwn.net/Articles/370421/"><img height="178" border="0" align="right" width="150" alt="[Ted Ts'o]" src="http://lwn.net/images/conf/lca2010/TedTso-sm.jpg"/> </a>

[Robert Krátký]

Především bych neměl zapomínat přenášet obrázky na server abclinuxu.cz - tím by se mnoho věcí vyřešilo...

[Martin]

Mě teď zarazila jedna věc. Ve stabilním jádře jsem narazil na chybu, která způsobuje zatuhnutí systému cca jednou za den. Chybu jsem našel nahlášenou asi od listopadu minulého roku.

Myslel jsem, že v takovém okamžiku se všechno zastaví a všichni začnou řešit tento problém. Přece není možné, aby jádro jen tak při zátěži tuhlo.

Kdepak. Nikoho to nezajímá. Nikdo podrobnosti nehledá. Nikdo se nesnaží pád nasimulovat. "Čekejte na další verzi, třeba se to spraví samo." Docela mě to udivilo, měl jsem o vývoji jádra jiné představy.

[Nikola Ciprich]

to zalezi... ja resim podobne problemy docela casto, ve vsech moznych castech jadra (nebo i jineho sw), a autori jsou vetsinou ochotni pomoct, ale clovek se musi nekdy trochu snazit i sam, nestaci rict - mi to nefunguje, opravte mi to, ale treba aspon priblizne odhadnout kde chyba je, poslat co nejvice ladicich informaci atd. a docela casto se pak stane ze si chybu uz rovnou opravi sam a jen posle patch :)

[JoHnY2]

Mas pravdu, ale rochnit se v jadru je pro vetsinu administratoru docela problem. Obzlast blby je, kdyz se objevi bug v novy verzi SW na produkcni masine. Admin nemuze strelit firemni mailserver/db/... a jit si den hrat s debugovaci nastrojema.

[Marek 'marx' Grác]

Druhá možnosť pre ľudí, ktoré nemajú túto schopnosť je zaplatiť si podporu :)

[Jakub Lucký]

Hlásil jste to na distribuci, nebo přímo do kernelu? V distribuci většinou bývá člověk, co se právě těmahle věcma zabývá... V Debianu se obvykle ozve docela rychle (oproti jiným maintainerům) a často aspoň poradí workaround...

[Karry]

Pošli link na bug. Je nějaký zaručený způsob jak to reprodukovat? Chyby které se projevují u malé skupinky uživatelů jsou většinou způsobeny ovladači. Jaký nestandardní hw používáš? Já osobně nesleduji všechny bugy, pouze ty které se osobně týkají, nebo ty které způsobují ovladače jejiž kód znám... Člověk občas musí zařvat aby ho bylo slyšet :)

[thingie]

Já mám pocit, že ten článek of filesystémech jsem tady už četl. Nebo možná na LWN v originále? Strašně se mi to plete. Mělo by se to spravit.

[michich]

Pokud čteš LWN.net pravidelně, takovýto pocit máš správně mít při čtení Jaderných novin pokaždé

[thingie]

To je právě to, že nečtu. Ale občas jo.

[stativ]

Tak si říkám, že pod každými jadernými novinami jsou vždycky diskuse jen co se týče překladu a dalších estetických kravin místo toho aby se řešily důležitější věci, jako je devtmpfs. O kterém si myslím, že je to naprostá kravina a v jádře nemá co dělat (buď to mělo přijít před udevem, nebo nepřijít vůbec).

V současné době to neřeší vůbec nic (s výjimkou emebeded zařízení, které stejně budou nejspíš používat něco na způsob statického /dev). Klidně ať si tvrdí, že je to lepší než udev, protože to používá informace, které už jádro má (kdežto udev je znovu „vykopává“ ze sysfs) ale stejně se nakonec udev bude muset spustit. Radši ať upraví příslušná rozhraní které udev používá tak, aby měl ty informace dispozici hned.

Důvod, že boot bude na některých systémech rychlejší neberu (nehledě na to, co jsem řekl výše, že udev se stejně bude muset spustit), spouštění udevu za normálních okolností trvá chvilku. Takový HAL zabere desetkrát tolik času.

[vlastikroot]

No ... u mě trvá start udevu tak 6 sekund (přitom načítá ty moduly), přitom je to pitomost. Já jsem za devtmpfs rád, však ty soubory v /dev jsou to jediný, co člověk potřebuje pro běh. Nějakej HAL, bez toho by se člověk i obešel. A pořád lepší opravdu funkční dynamický /dev jako je to na normálních unixech, než statická patlanina. Imho je největší výhoda devtmpfs v přidání souboru, hned jak ho dá ovladač k dispozici, místo toho aby to dělal udev najednou (a pak to trvalo těch 6 sekund).

[stativ]

Konečně trochu smysluplná diskuse.

Podle mě právě tohle by šlo udělat nějakým zlepšením rozhraní udevu. V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd. Takže by se to (možná) dalo udělat tak, že udev vytvoří základní strukturu /dev a systém začne vesele bootovat dál zatímco se /dev zaplňuje. Taky nevěřím tomu, že devtmpfs bude stejně konfigurovatelný jako udev.

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly. V nemodulárním systému na desktopu start udevu zabere myslím kolem 500ms. Jakmile jsem použil distribuční jádro s moduly, trvalo to několikanásobně déle. Rozdíl tedy podle mého je způsoben nahráváním modulů. Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát. Možná by to jádro zvládlo rychleji, možná by to trvalo úplně stejně dlouho.

Jen tak mimochodem – bojím se, že řetěz xkb–HAL–udev v X.org bude pokračovat.

[Ondrej 'SanTiago' Zajicek]

Ja mam s udevem presne opacnou zkusenost - jeho start trva dlouho vcelku bez ohledu, zda zavadi moduly, nebo zda jsou moduly uz zavedene.

[stativ]

Holt jsem tedy klikař .

[Ondrej 'SanTiago' Zajicek]

Respektive tedy ne samotny start demona (ten je rychly), ale cela startovaci sekvence:

udevd --daemon
udevadm trigger
udevadm settle

Ktera spousti a ceka na dokonceni prehrani udalosti z bootu.

[trekker.dk]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly.

Neřekl bych - nemůžu říct, jestli je to na všech distrech, ale v Debianu se moduly nahrávají až když je udev a podobné nastartovaný (samozřejmě kromě těch nutných pro start systému). Takže udev nastartuje s minimální konfigurací (jádro + pár modulů), pak systém bootuje dál a v určité fázi se natáhnou věci zapsané v /etc/modules. A ani tam nemusí být všechno, hodně modulů se natáhne až když jsou potřeba (USB mass storage atd.)

Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát.

Já měl za to, že o nahrání modulu rozhoduje jádro, když je modul zapotřebí k zařízení, které se právě detekovalo, a udev jenom vytvoří odpovídající soubory v /dev

Jen tak mimochodem – bojím se, že řetěz xkb–HAL–udev v X.org bude pokračovat.

Zatím naštěstí několik let úspěšně žiju s tím, že HAL vypínám a zakazuju.

[stativ]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Minimálně v případě console máš nejspíš pravdu. To nic ale nemění na tom, že v současnosti coldplug připojuje úplně všechno, co je připojené předtím, než boot pokračuje. Přitom by stačilo to málo aby boot mohl pokračovat. Do doby než např. nastartují X-ka se pak detekují i věci jako je myš a klávesnice, flashka a další zbytečnosti.

Osobně si myslím, že za těch 6 sekund ani tak nemůže udev jako samotné jádro, které nahrává moduly.

Neřekl bych - nemůžu říct, jestli je to na všech distrech, ale v Debianu se moduly nahrávají až když je udev a podobné nastartovaný (samozřejmě kromě těch nutných pro start systému). Takže udev nastartuje s minimální konfigurací (jádro + pár modulů), pak systém bootuje dál a v určité fázi se natáhnou věci zapsané v /etc/modules. A ani tam nemusí být všechno, hodně modulů se natáhne až když jsou potřeba (USB mass storage atd.)

Možná ale udevu dlouho trvá rozhodnout se, jaký modul nahrát.

Já měl za to, že o nahrání modulu rozhoduje jádro, když je modul zapotřebí k zařízení, které se právě detekovalo, a udev jenom vytvoří odpovídající soubory v /dev

No, udev umožňuje nahrávat při hotplugu potřebné moduly (a případně provádět i skripty). Stoprocentní důkaz nemám, ale většinou je module autoloading zmiňován spolu s udevem. Např. Arch wiki: „udev loads kernel modules simultaneously, which can provide a speed increase during bootup.“. Gentoo wiki to neříká tak okatě, ale opět zmiňuje autoloading modulů v souvislosti s udevem. Podobně se o něm zmiňují i v LFS a Mandriva dokumentaci.

Tím neříkám, že to dělá udev, ale to, že to na mě tak působí.

Zatím naštěstí několik let úspěšně žiju s tím, že HAL vypínám a zakazuju.

Já už rezignoval.

[trekker.dk]

Minimálně v případě console máš nejspíš pravdu. To nic ale nemění na tom, že v současnosti coldplug připojuje úplně všechno, co je připojené předtím, než boot pokračuje. Přitom by stačilo to málo aby boot mohl pokračovat.

Otázka je, jak definuješ to málo, které stačí. Patří tam disk (ovladače řadiče a spol)? Když bootuješ ze sítě, tak ne.

Patří tam síť? Pokud bootuješ lokálně, tak ne. Pokud jsou části systému na síti (např. /usr/bin a spol.), tak už jo.

Takhle by se dalo pokračovat. Klávesnice může být potřeba, aby mohl zadat heslo k šifrovanému oddílu před bootem.

Pokud nevymyslíš způsob, jak nastavit, co je potřeba a co může počkat - tak, abys to mohl sdělit jádru - tak má jádro jedinou možnost a sice připojit všechno, co se nadetekovalo.

[petr_p]

Ovladače obsahují identifikátory podporovaných zařízení. Když si do jádra zakompilujete automatické zavádění modulů, tak jádro, vždy když najde nové zařízení na sběrnici, tak zavolá /proc/sys/kernel/modprobe a v argumentech mu předá alias zařízení. Tohle funguje bez udevu. Jádru se zařízení objevují a jádro zavádí moduly od určité rané verze 2.6 asynchronně.

Samozřejmě stejnou úlohu může zastat udev, který se o novém zařízení dozví od jádra přes netlink, alias si zjistí ze sysfs a nakonec stejně zavolá modprobe.

[stativ]

Ovladače obsahují identifikátory podporovaných zařízení. Když si do jádra zakompilujete automatické zavádění modulů, tak jádro, vždy když najde nové zařízení na sběrnici, tak zavolá /proc/sys/kernel/modprobe a v argumentech mu předá alias zařízení. Tohle funguje bez udevu. Jádru se zařízení objevují a jádro zavádí moduly od určité rané verze 2.6 asynchronně.

Samozřejmě stejnou úlohu může zastat udev, který se o novém zařízení dozví od jádra přes netlink, alias si zjistí ze sysfs a nakonec stejně zavolá modprobe.

Díky za osvětu.

[Josef Kufner]

V podstatě důvod, proč se na udev čeká než se spustí cokoli jiného je vytvoření základního /dev (console, null, zero). Ani to zařízení disku není potřeba pokud jsou potřebné věci v initrd.

Není to náhodou tak, že ty základní věci jako console tam už musí být před startem udevu? Pokud si vzpomínám, s prázdným /dev si jádro stěžuje, že can't open initial console

Před startem udevu je na / adresář /dev, který obsahuje základní sadu souborů pro případ, že by udev nenastartoval (jsou tam i disky a podobné věci). Jakmile udev nastartuje, tak mountne do /dev tmpfs a začne vytvářet všecky ty speciální soubory.

[trekker.dk]

No jasně, to jo. Ale moje otázka byla, jestli jádro vůbec nabootuje, když bude před startem udevu ten /dev úplně prázdný. Moje zkušenosti s tou výše zmíněnou hláškou naznačují, že ne.

[cronin]

Tak si říkám, že pod každými jadernými novinami jsou vždycky diskuse jen co se týče překladu a dalších estetických kravin místo toho aby se řešily důležitější věci, jako je devtmpfs.

Ide o to, ze tunajsie diskusie mozu mat dopad na preklad a ostatne "esteticke kraviny", zatial co na devtmpfs, otazky zivota, vesmiru a vobec, dopad asi mat nebudu.

[trekker.dk]

Když ti devtmpfs tak vadí, tak si ho vypni. Nikomu to neškodí, udělané je to dobře, tak proč to nezačlenit?

[stativ]

Vypínat ho nebudu, protože ho v jádře nemám.

[kralyk z abclinuxu]

Vzhledem k tomu, že 32 bitů pro jakýkoliv stroj s více než 1 GB paměti znamená HIGHMEM, ne-embedded stroje, na kterých by dnes měla běžet 32bitová jádra, v podstatě tvoří prázdnou množinu. Bohužel linuxová distra nedostatečně propagovala 64bitová jádra pro 32bitové distribuce; i když čistých 64 bitů je lepší, i tak by bylo sakra lepší, kdyby lidi používající 32 bitů kvůli kompatibilitě měli rozumnější alternativu.

Hehe, tohle číst Jardík, tak klekne na koberec a několikrát skloní hlavu ve směru Mekky Helsinek

[trekker.dk]

Na druhou stranu minule se psalo něco o tom, že 64bitová jádra byla v jednom ohledu pomalejší než 32bitová