Co je multicast na loopbacku? (multicast - adresa Ex.xx.xx.xx, loopback - adresa 7F.xx.xx.xx hexa) Pokud myslíte broadcast, tak by to jednak přinášelo zajímavé situace typu najdi volnou adresu na který se dá poslouchat, druhak by ten počítač nemusel rozdýchat když by vložení CD probudilo třeba všechny KDE aplikace. Pokud byste použil unix domain sockety, tak by to potenciálně znamenalo n^2 spojení, kromě toho byste nějak musel poznat jaký socket patří jaké aplikaci příp. jaké její instanci.
Tohle DBUS řeší. Vytváří jakousi síť s hvězdicovou topologií, směruje v ní data a dokáže zjistit, jaké jsou v té síti "služby".
MMCH, DBUS používá unix domain sockets, jak se můžete přesvědčit: lsof | grep dbus
. Takže ta otázka nedává moc smysl, DBUS je prostě na jiné úrovni. Asi jako "K čemu je CORBA, vždyť na komunikaci můžu použít UDP"
Přechod na udev byl bolestný a nepříjemný. Jednoduchá struktura statických souborů reprezentujících zařízení v systému byla nahrazena změtí pravidel, ve kterých se vyznat je nad síly mnoha uživatelů.
Kdyby byla ta struktura opravdu tak jednoduchá a praktická, tak by nejspíš nebyl důvod udev vůbec napsat, natož na něj přecházet...
Na OpenSuSE 9.3 tam těch souborů bylo přes 9000. Greg Kroah Hartman uvádí, že na nějaké konkrétní verzi Red Hatu to bylo asi 18000. To vám připadá přehledné a jednoduché? Porovnám-li to s 800 pravidly, z nichž dvě třetiny má na svědomí libsane
a která jsou okomentovaná a roztříděná do jednotlivých souborů podle toho, čeho se týkají, nevím, nevím...
Vezmu-li navíc v úvahu, že čím dál víc zařízení jádro nemůže persistentně pojmenovat už z principu, je udev logickým a v podstatě nutným východiskem.
Pokud vím, udev vznikl primárně jako reakce na to, že se devfs neosvědčil. A taky na to, že pořádně nefungoval a poté, co se o něj přestal starat původní autor, nenašel se nikdo, kdo by ho byl ochoten dát dopořádku nebo aspoň udržovat. Hlavní problém vidím v tom, že vzhledem k implementaci v jádře byl prakticky nekonfigurovatelný, takže mi není jasné, do jaké míry (pokud vůbec) mohl zajišťovat persistenci jmen zařízení.
Používala vlastně devfs nějaká jiná běžná distribuce než Mandrake?
Nemyslim, ze by neprehlednost souvisela s mnozstvim. I kdybych mel specialnich souboru treba 100000, porad by to byly primitivni specialni soubory na kterych nejde prakticky nic pokazit.
Ani na starém ext2 bez indexovaných adresářů to není problém? Ani na embedded systémech? Ani na rescue systému?
Asi je to tim, ze jsem s unixy delal uz v dobe, kdy vetsina zdejsich ctenaru jeste ani nevedela, ze existuje nejaky Linux (a on tenkrat byl vlastne jen mimino).
V mém případě se první zkušenosti s unixovými systémy datují do roku 1992. Ale to neznamená, že se budu dívat na všechno, co tu v roce 1992 nebylo, jako na neunixové novoty, které je třeba zadupat do země.
Z tohoto duvodu jsou mne proti srsti napr. i fanaticke vykriky, jak je napr. svatokradezne na Linuxu pouzit prikaz ifconfig.
To není svatokrádežné, to je jen hloupé. Používat ke konfiguraci jaderných objektů rozhraní založené na koncepci, která už 9 let v jádře není, které mi podle nálady někdy ukazuje neexistující objekty, jindy neukazuje existující a občas pro zpestření na požadavek na operaci s objektem A provede tuto změnu bez varování na objektu B (protože A ve skutečnosti neexistuje a příkaz jeho existenci pouze předstírá), to je ten váš "unixový přístup"? Ten náboženský přístup a obvinění ze svatokrádežnosti jsou ve skutečnosti typické spíše pro lidi, kteří uvažují jako vy, lidé, kteří se zuby nehty brání jakékoli změně a každý pokus o novou koncepci šmahem odmítají jako "neunixový".
Horsi zalezitosti je HAL. Nic neunixovejsiho jsem snad na Linuxu jeste nevidel.
A jsme zpátky u toho hlavního problému: čím se měří ta unixovost? Tím, jestli to vymysleli v 70. letech nebo až v 80.?
Neprehledne, komplikovane, spatne zdokumentovane, mnohdy si to dela co chce...
Připadá vám přehlednější a méně komplikované zjišťovat informace o hardwaru přes deset různých rozhraní na deseti různých místech? Špatně zdokumentované... kéž by bylo všechno zdokumentované aspoň tak špatně jako HAL. Mnohdy si dělá co chce... také jsem měl párkrát ten pocit, i od plic jsem si zanadával. Jenže nakonec jsem pokaždé zjistil, že chyba byla na mé straně.
Ne, HAL opravdu neslouží k tomu, "aby si aplikace mohly popovídat"; nepletete si to s D-BUS?
HAL (Hardware Abstraction Layer) umožňuje aplikacím (i uživateli) získávat informace o hardwaru a dalších prostředcích přes jednotné rozhraní. Vy možná dáváte přednost tomu, že budete informace o každém zařízení získávat jinde a jinak (a často i na několika různých místech pro jedno zařízení), ale zdá se, že řada vývojářů má jiné preference. Navíc HAL umožňuje ty informace doplnit a opravit (některá zařízení o sobě neříkají celou pravdu nebo o sobě dokonce nehorázně lžou) a definovat i politiky (pravidla, jak se má s daným zařízením nakládat).