Gentoo zvažuje fork udev (diskuse)

[mess]

Udev je jedna věc, ale co takový consolekit? Ten se taky v podstatě integroval do systemd.

[little.owl]

Ten se taky v podstatě integroval do systemd.

Byt jsem zastance systemd, tak tohle mi vadi. Ja chci systemd jako modul, bez nejz bude mozno OS provozovat.

[blami]

Jedine co je potreba (a oni to asi nevi, nebo jim to vadi) je, ze aby ze systemd vypadl (stale izolovany) udev je potreba zkompilovat cely systemd. Me fascinuje jak lidi rikaji ze je to monolit - podivejte se do toho baliku, je to gazilion malych modulu, ktere jsou navrzeny UNIX in mind, maji mezi sebou pekne rozhrani (DBus, ktery miri do kernelu btw.), jen je to v jednom velkem baliku (coz ted po rozdeleni livetexu ve fedore beru docela s povdekem).

[pavlix]

podivejte se do toho baliku, je to gazilion malych modulu, ktere jsou navrzeny UNIX in mind

To si představuju trochu jinak.

DBus, ktery miri do kernelu

D-Bus může mířit třeba na měsíc, ale neříká to nic o tom, jeslti se tam dostane. A ani D-Bus není zrovna „unix in mind“, i když by být mohl.

jen je to v jednom velkem baliku

Zrovna v Gentoo by to díky use flagům mohlo jít ještě používat, za předpokladu, že se bude dlouhodobě udržovat patchset, který vrátí funkcionalitu, kterou vývojáři systemd odstraní.

[little.owl]

V prvni rade nebyl zadny duvod to davat do jednoho stromu.

DBus, ktery miri do kernelu btw.

Uvidime.

[kouzer]

Gentoo se mi zamlouva cim dal vic. Treba se nekteri zamysli az uzivatele prejdou na non-systemd distra....

[Limoto]

+1

[Limoto]

Ale kdo to má furt kompilovat...

[Dadam]

Co Sabayon?

[rADOn]

Od toho mame prece pocitace

[pavlix]

No já ne, od toho mám počítač. Zkompilovat Gentoo není o moc náročnější než před deseti lety. Zato počítače jsou podstatě výkonnější.

A pak je tu Sabayon, takže argumentovat nutností lokální kompilace je liché.

[the.max]

gcc?

[pavlix]

+1

[vvv]

Co je vlastne potreba upravovat v aplikacich, aby mohli plne vyuzivat moznosti systemd? A ted nemyslim konkretne udev, ale obecne vse mozne.

[tsLnox]

Hlavně je třeba upravovat uživatele, dost často na hodně nízké úrovni

[pavlix]

Záleží, co ty aplikace potřebují. Nedováno do systemd přešel session management. Takže když chci něco povolit jen uživateli, který je fyzicky přihlášený, musím se ptát SystemD (jinak jsem se ptal ConsoleKitu).

Udev byl dosud považován za klíčový software nezávislý na init systému a spoléhají na něj distribuce včetně Gentoo. Takže chápu, že se jim to nelíbí.

[blami]

Udev byl dosud považován za klíčový software nezávislý na init systému a spoléhají na něj distribuce včetně Gentoo. Takže chápu, že se jim to nelíbí.

Udev je stale nezavisly na systemd, ne?

[pavlix]

Býval.

[blami]

Stale je.

http://pastebin.com/WtxeS4db

[pavlix]

Non sequitur.

[jyrki]

+1

[little.owl]

Zalezi na Debianu, samotne Gentoo s tim nic neudela. Prejit nestaci, pokud tu nebude SW, ktery bez systemd muze rozumne fungovat a tech lidi, ktery systemd integruji je plno.

[pavlix]

Gentoo po leta prokazovalo schopnost udržovat některé věci odlišné od zbytku linuxového světa. Nicméně spolupráce s Debianem by hodně pomohla.

[little.owl]

Ja nepochybuji o schopnostech Gentoo, ale pokud zustanou sami, nemyslim ze jsou to schopni utahnout. Man-hours. Koukni se jak dlouho trvalo vyjmout zavislosti na HAL a to na tom pracovali vsichni.

[the.max]

mno, ja od Gentoo odesel k Archu, ale posledni dobou mam cim dal silnejsi nutkani se zase vratit ke Gentoo.

[Jooky (inactive)]

udev ma cim dalej tym viacej vytaca. Gentoo pouzivam na vsetkych mojich linux masinach uz dlhe roky a jediny soft, s ktorym je stale nejaky problem je udev. V kazdom jednom update pridavaju nejaku bizardnu zmenu a v konecnom dosledku ten soft treba po kazdom update presviedcat k poslusnosti. Na serveroch malo kedy updatujem udev, lebo po kazdom update ma nejake zariadenie ine prava, vlastnosti, alebo config je odignorovany pre zmeny zapisu pravidiel. Zavislost na /usr, ktora sa spomina v spravicke, je podledna kvapka. Nechapem ako moze soft, ktory startuje ako prvy, popripade v ramdisku, mat runtime zavislosti na /usr.

na mojich servroch nedochadza k velkym zmenam HW, takze som uz zvazoval staticky /dev + nejake svoje scripty. Vidiet, ze problemy s udevom netrapia len mna. Fork plne podporujem. Ked sa do niecoho pusti gentoo team, tak to bude na vysokej urovni.

[Ondrej 'SanTiago' Zajicek]

Pokud mas staticky system, tak nepotrebujes udev, ani neni treba resit staticky /dev, ale uplne staci devtmpfs. Sam to pouzivam na routerech.

[pavlix]

Spousta věcí na udevu závisí.

[Ondrej 'SanTiago' Zajicek]

Co konkretne? Na svem desktopu mam udev, ale pouzivam ho jen kvuli zmene prav a skupin dev souboru a pro natahovani firmware. Na serverech tyhle veci typicky nejsou potreba, takze devtmpfs postaci. Natahovat firmware zrejme brzy bude umet kernel sam, takze dalsi duvod odpadne.

[pavlix]

Když si postavíš custom distribuci nebo použiješ nějakou, která bez Udevu stavěná a poskytuje ti vše, co potřebuješ, tak je to v pořádku. Ale já osobně do budoucna na serverech počítám s NetworkManagerem, který v tuto chvíli na Udevu závisí kvůli zjišťování informací o rozhraních. Musel by se upravit tak, aby si tyto věci zjišťoval přímo, ale v tuto chvíli se na udev spoléhá i ohledně zajištění jednoznačných názvů.

[lyon]

NetworkManager na serveru? Proc proboha?

[pavlix]

Proč network démona na serveru, o tom jsem mluvil na LinuxDays a LinuxAltu. Pokud používáš na serveru pouze statickou konfiguraci, jsou nadbytečné i network skripty, ale na ty se nikdo neptá, že.

Takže prvně má smysl se bavit o požadavcích, pak teprve o nástrojích na jejich naplnění.

V reálu lidé na serverech používají i DHCP. Některého DHCP klienta lze zneužívat jako network démona, ale na problémy narazíš ve chvíli, kdy chceš provozovat DHCP na dvou rozhraních či použít dynamickou konfiguraci IPv6.

Lidi od virtualizace vyžadují i další vlastnosti jako checkpointing a návrat k předchozí konfiguraci při ztrátě konektivity.

Network démona bude mít i OpenWRT.

[l4m4]

Pokud používáš na serveru pouze statickou konfiguraci, jsou nadbytečné i network skripty, ale na ty se nikdo neptá, že.

Ale ptá. Jenže network scripty jsou zcela tupé a na jakoukoli změnu reagují tak, že ji ignorují a dělají přesně to, co dělaly vždycky už patnáct let. Takže boj s nimi je snadný. NetworkManager, to je naproti tomu mnohem zákeřnější soupeř.

[pavlix]

Takže boj s nimi je snadný. NetworkManager, to je naproti tomu mnohem zákeřnější soupeř.

O tom se nepřu. Nicméně všem bojovníkům s NetworkManagerem nabízím spojenectví na půdě bugzilla.gnome.org, kde na produktu NetworkManager, komponentě general sleduju bugreporty až několikrát do týdne.

Takže všem, kteří z nějakého důvodu nechtějí nebo nemůžou žít bez NetworkManageru říkám, ať využijí toho, že je Red Hat ochotný platit někoho, kdo má dost podobné smýšlení a přitom pracuje na takto ošklivém projektu.

[Ondrej 'SanTiago' Zajicek]

Jo, jeste mozna module autoloading, tam si nejsem jist, zda do toho udev zasahuje, ale pred udevem to kernel resil primo pomoci modprobe, takze i bez udevu to AFAIK funguje.

[Jooky (inactive)]

Presne tak. Nejaky jednoduchy network device, popripade zberac dat z GPS si viem predstavit bez udevu, ale server ani nie. LVM bez intergracie s udevom nie je az tak moc pouzitelne, ked sa k tomu prida mdraid a zariadenia na USB zbernici, tak bez udevu, alebo jeho nahrady sa to neda. Napr. USB zariadenia maju dynamicke minor cisla a aj ked normalne idu sekvencne, tak nikto negarantuje v akom poradi ich "kernel" objavi.

Predchadzajuci boot boli cisla sekvecne od 1 po 4, teraz su uplne opacne. Bohvie co bude po daljsiom reboote :)

$ ls -ld /dev/dvd-ram_drive_*
lrwxrwxrwx 1 root root 3 Nov 13 19:05 /dev/dvd-ram_drive_A -> sr4
lrwxrwxrwx 1 root root 3 Nov 13 19:05 /dev/dvd-ram_drive_B -> sr3
lrwxrwxrwx 1 root root 3 Nov 13 19:05 /dev/dvd-ram_drive_C -> sr2
lrwxrwxrwx 1 root root 3 Nov 13 19:05 /dev/dvd-ram_drive_D -> sr1
$

[mirec]

Go Go Go Gentoo! Môže sa začať nová éra globálneho otepľovania

[Jakub Lucký]

Kde jim můžu poslat nějaké $ na vývoj?

[blami]

Nez zacnete posilat ty prispevky na vyvoj podivejte se co Ti lidi delaji. Z toho co jsem videl ja totalne netusi co delaji a delaji to absolutne zbytecne a na zaklade absolutne nesmyslnych predpokladu.

https://github.com/gentoo/eudev/commit/151d9085b438a6c6bb50385c99f3f1969620114b https://github.com/gentoo/eudev/commit/a91a7609b204ba01037df4ab314dc81c0589c8cb

[Nikola Ciprich]

tez mam ten pocit. a zjevne nejsme sami...

https://plus.google.com/111049168280159033135/posts/R387kQb1zxc

[alfonz mucha]

to blkid je opravdu asi případ, kdy se asi moc nepodívali k čemu to vlastně je. Hm uvidíme co z toho vyleze a kdo ví, jak dlouho to vůbec vydrží...

[pavlix]

Než začneš soudit, pošli bug report. Lépe se to čte, dá se tam napsat přesně, co se ti nelíbí, aby si člověk mohl udělat trochu lepší obrázek. A hlavně, může to skutečně pomoct. Sám jsem už pár bugreportů na Gentoo napsal. Nevím jak to funguje na Udevu, ale ty, co jsem psal ohledně NetworkManageru, jsou už povětšinou zapracované.

[pavlix]

Ještě abych to upřesnil… viděl jsem hodně kontraproduktivních změn v kódu a mnoho z nich bylo od lidí, jimž nelze upřít podstatně větší přínosy jinde. Takže několik třeba i špatných změn pro mě není důvod hodit někoho přes palubu.

[little.owl]

Tam jde o neco jineho a to ze zmeny se delaji unilateralne, bez diskuze s ostanimi.

Pokud meli treba pocit, ze drivery loaduji firmware ve spatny cas, meli pockat dokud se to nevyresi na strane kernelu a ne to hodit na uzivatele pak zaskocenych tim, ze jim system na 30s zamrzne.

[little.owl]

OK, bezu zpet tohle nebyl ten problem .... rychle skenovani prispevku je spatne.

[pavlix]

Tam jde o neco jineho a to ze zmeny se delaji unilateralne, bez diskuze s ostanimi.

To je velmi častý problém. Ale zrovna v případě systemd a udevu se zdráhám to hodin jen na „ty druhé“.

Pokud meli treba pocit, ze drivery loaduji firmware ve spatny cas, meli pockat dokud se to nevyresi na strane kernelu a ne to hodit na uzivatele pak zaskocenych tim, ze jim system na 30s zamrzne.

?

[little.owl]

?

Here. Ale v kontextu toho co rikas je to irelevantni.

[pavlix]

OK.

[blami]

Nejak nechapu co bych mel reportovat a proc proti Gentoo kdyz tu distribuci ani nepouzivam ani neznam. Jsem spokojeny se systemd a rad, ze je udev soucasti stromu, zjednodusuje to spousta veci (napr. uaccess). Dokonce ani nemam nic proti forkum udev, jen me zarazi ze vsichni tu krici hura a doslova onanuji nad commity typu "nevime k cemu to je tak to vymazeme". Tot vse.

[----]

Vyhodit systemd, vyhodit udev, zavést znovu devfs (a najít maintainera).

[pc]

Poslední dobou pozoruju trend, že se nahrazujou nebo "vylepšujou" věci, který normálně fungujou a na nedodělky nebo chybějící aplikace se pořád kašle. Po těch x letech co používám linuxový distra na desítkách různých zařízení jsem žádný podstatný zlepšení od devfs, přes udev až k systemd nezaznamenal a ty důvody k opakovanému překopání správy zařízení prostě nepovažuju za obhajitelné. I na pitomým desktopu s devfs a KDE 3.x až na výjimky všechno fungovalo jak mělo.

Systém "vytvoříme problém tam kde není" ∧ "obhájíme vágními důvody zastaralosti, okrajovými případy vydávanými za běžné" ⇒ "budeme ho řešit od nuly a nezůstane kámen na kameni, spotřebují se (zbytečně) čas+energie+peníze". Zdaleka se netýká jen IT.

[pavlix]

A já pořád opakuju, že je to chyba nás konzervativních, že jsme příliš konzervativní a nestaráme se o vývoj toho, co funguje, aby to kromě fungování mělo i punc modernosti. Protože pak přijde někdo, kdo ten punc modernosti dodá, ale bez funkcionality.

[dustin]

A na to hned navazuje dalsi otazka - proc za tenhle vyvoj nekdo plati? Tohle urcite nepochazi od zapalenych nadsencu. Co delaji manazeri techto lidi? Posledni dobou mam porad vetsi pocit, ze jde o aktivity placenych zamestnancu s cilem vykazovat cinnost a udrzet si tak slusne placeny flek bez vetsich starosti.

[pavlix]

Oni i ti manažeři mají svá přání. Jak ta, která se týkají skutečného užitku zákazníkům, tak takové ty drobnosti, které by se líbily jim osobně. Kvalitní nižší manažer si upraví požadavky vyššího manažera trochu více do reality a dosavadních zvyklostí. Kvalitní pěšák upozorní nižšího manažera na případné nesrovnalosti.

Nevím jak u jiných, ale v případě jistých němců si myslí, že oni tomu, co dělají do jisté míry věří. A hlavně věří ve svou jedinečnost a úžasnost. Tudíž kdokoli, kdo je kritizuje, prostě a jednoduše nemá pravdu. K čemuž přispívá to, že je kritizuje spousta hlupáků, které si oni pak můžou vybrat jako příklady toho, že kritika vůči nim je nesmyslná.

Jinak každému přeju, aby tyhle lidi viděl osobně na schůzi a při práci, nebo třeba i na firemním meetingu. Člověk tak leccos pochopí, co mu dosud bylo naprostou záhadou.

[little.owl]

Nevím jak u jiných, ale v případě jistých němců si myslí, že oni tomu, co dělají do jisté míry věří. A hlavně věří ve svou jedinečnost a úžasnost. Tudíž kdokoli, kdo je kritizuje, prostě a jednoduše nemá pravdu. K čemuž přispívá to, že je kritizuje spousta hlupáků, které si oni pak můžou vybrat jako příklady toho, že kritika vůči nim je nesmyslná.

Diky za tuhle informaci.

[pavlix]

Diky za tuhle informaci.

Já doufám, že to bylo myšleno vážně a ne ironicky :).

[dustin]

Dobře, ale i Lennart má přece svého šéfa. To jsou manažeři v RedHatu takové bačkory, že si jej neumí dát do latě? Je nesporně velice dobrý technik, ale očividně k sobě potřebuje protipól s nohama pevně na zemi, který jej bude směrovat do reality života/byznysu/udržitelného softwaru a ne jeho vysněného dokonalého všeobjímajícího řešení. Nemyslím si, že by z megalomanství těchto projektů měl RH nějaký užitek, budou bojovat se stejnými problémy jako všichni ostatní uživatelé takového řešení. Nebo je vývoj v RH taková anarchie, že si tam hvězdy vývojáři dělají, co chtějí?

[pavlix]

Dobře, ale i Lennart má přece svého šéfa.

Co jsem k tomu řekl, to jsem k tomu řekl. Podrobněji už se ze své pozice nemůžu k tématu vyjádřit a nechám diskutovat jiné.

[asdgfadsf]

Lennart bohuzel svymi nesmyslnymi, ale na manazery dobre pusobicimi "argumenty" vzdycky zapusobi. Aneb kdyz nekdo napise 30 bodu proc systemd, z nichz 28 jsou obecny kecy a dva z toho jsou spekulativni, tak to proste na manazery dobre pusobi, protoze maji pocit, ze tim zakaznikovi daji neco novyho, neco super.

[Michal Karas]

To jsem si říkal už u zprávičky o journalu a FSS, jak je možné, že mu něco takového projde.

[mrv]

ten text zpravicky je zavadejici...ve skutecnosti v gentoo neni zadne rozhodnuti v tomto smeru. tenhle fork je ve skutecnosti projekt nekolika z gentoo vyvojaru a ne gentoo jako takoveho...

ta uroven zpravicek tady je zoufala...a uroven diskuteru taky. stravit 5 minut zjistenim si informaci je asi moc...ironii je, ze plno lidi tu furt mele o tom, ze "bezny" lidi jsou ovce. a pritom oni sami se daji manipulovat az komicky snadno...

[little.owl]

ten text zpravicky je zavadejici...

Takze po precteni odkazaneho threadu mi chcete tvrdit, ze oni nic takoveho nezvazuji? Nic jineho totiz ve zpravicce netvrdim.

.ve skutecnosti v gentoo neni zadne rozhodnuti v tomto smeru.

Tvrdim snad ze nejake rozhodnuti bylo ucineno?

ta uroven zpravicek tady je zoufala...a uroven diskuteru taky. stravit 5 minut zjistenim si informaci je asi moc...ironii je, ze plno lidi tu furt mele o tom, ze "bezny" lidi jsou ovce. a pritom oni sami se daji manipulovat az komicky snadno...

S ohledem na interpretaci zpravicky mam urcite pochybnosti o vasi urovni, diskuteri nahore jsou OK.

[Grunt]

Co furt všichni mají proti systemd, nechápu.

[lyon]

Protoze je to kurvitko.

[Grunt]

Mě to funguje.

[lyon]

Mě initscripty taky.

[nyan]

To je nejlepsi argument vsech dob.

[Grunt]

Tak dobrý, ale proč bych se měl starat o nějaké lamky co rády vrtají do systému a přitom to moc neumí? (a ke všemu ještě nepoužívají Fedoru)

[j]

Protoze ty "lamky" radsi videj do toho, co to dela, nez pouzivani nejaky cerny magie, u ktery clovek nikdy nevi, co se kde podela a bez nich ani tobe nebude fungovat nic.

[Grunt]

To je těžké:

• SysV-style init skripty
• Jsou sice v BASHy, tudíž vcelku jednoduché
• Ale zároveň díky tomu, že jsou v BASHy jsou docela pomalé (při každém startu se provádí to samé a řeč o masivním forkování už byla)
• Díky tomu že jsou v BASHy sice dávají iluzi, že do nich lze lehce zasahovat bez znalosti nějakého jazyka (lames can do it), jenže podobně jako třeba zásah do configure scriptu zásah do init scriptu není jednoduchý a bez velice dobré znalosti pozadí v 90% případů spíš akorát něco rozbije (má vlastní zkušenost — do init skriptů se nevyplatí zasahovat)
• Na druhou stranu, a myslím že populární termín je „robustnost“, takže je to robustní — když se během bootu něco pokazí, vyskočí konzole, díky jednoduchosti BASHe se dá chyba snadno (relativně proti Céčku) najít, opravit a v bootu pokračovat
• systemd
  • Je v Céčku, takže rychlí a snadno předvídatelný
  • Díky unifikaci nastavení i strojově zpracovatelný
  • A i když se to nezdá, tak i editovatelný — stačí si udělat úpravu ve zdrojácích, zkompilovat, nasadit a restartovat. Zas na druhou stranu chápu že v porovnání s BASHem nic moc. Ale nějaký BASHový skript kde si můžou lamáci do BASHe cpát příkazy po spuštění to snad spouští, ne?
  • buď prostě nabootuje nebo ne — že by to při startu někdo lepil v GDBčku si moc iluze nedělám

Hmm, těžká volba. Sám nejsem rozhodnutý co je lepší. Jako chápu nářky administrátorů kteří, když se při startu něco pokazí, honem rychle, rychle něco lepí v BASHových init skriptech (se systemd už to prostě nepůjde), jenže to je vadný argument protože si stačí vzpomenout na ty tisícovky serverů co startují jen při konjunkci všech planet sluneční soustavy, u kterých je update (kvůli zásahům v skriptech které obstarává balíčkovací systém alias nehrab na to dokud to bootuje) sprosté slovo a které už pravděpodobně za 100let nikdo nezreprodukuje.

[pavlix]

Na druhou stranu, a myslím že populární termín je „robustnost“, takže je to robustní — když se během bootu něco pokazí, vyskočí konzole, díky jednoduchosti BASHe se dá chyba snadno (relativně proti Céčku) najít, opravit a v bootu pokračovat

Řekl bych, že při správné implementaci konceptů SystemD-like initu je výsledek stokrát robustnější než initskripty.

buď prostě nabootuje nebo ne — že by to při startu někdo lepil v GDBčku si moc iluze nedělám

Já si zas nedělám iluze, že by se někdo běžně hrabal v těch interních skriptech, ze kterých se initscripty volají. Dle mého názoru je potřeba srovnávat srovnatelné, tedy initscript versus unitfile.

Já jsem osobně rozhodnutý pro koncept buď ve stylu SystemD (deklarativní konfigurační soubory) nebo OpenRC (skriptování za pomoci předpřipravených funkcí).

Jedno je založené na binárce a konfigurácích, druhé na skriptech a initskriptech (a minimalistické binárce ze sysvinitu). A přitom mají podle mě k sobě daleko blíž než OpenRC initskripty a klasické initskripty.

rychle něco lepí v BASHových init skriptech (se systemd už to prostě nepůjde),

V SystemD to jde úplně stejně, jen se to ještě nenaučili. Tedy pokud se pokazí ta část, které odpovídají initscripty. Nesmí se pokazit ten zbytek, ale to se v initskriptech neopravilo ani dosud.

[Grunt]

SystemD

systemd. Ne SystemD nebo System D nebo bůh ví co.

Řekl bych, že při správné implementaci konceptů SystemD-like initu je výsledek stokrát robustnější než initskripty.

Tož až to bude vyladěné, tak asi jo (Céčko a konfiguráky jsou prostě Céčko a konfiguráky).

Já si zas nedělám iluze, že by se někdo běžně hrabal v těch interních skriptech,

Se tam do toho nějaké lamky zasahují.

Dle mého názoru je potřeba srovnávat srovnatelné,

No ty si srovnávej co chceš…

V SystemD to jde úplně stejně

Ale houby. Některé pokud nemají proměnou tak jinak než rekompilací nepřelepíš.

[pavlix]

systemd. Ne SystemD nebo System D nebo bůh ví co.

Pardon.

No ty si srovnávej co chceš…

Budu. Srovnatelné, ne nesrovnatelné :).

Ale houby. Některé pokud nemají proměnou tak jinak než rekompilací nepřelepíš.

Nechtěl bys to zkusit podložit nějakým konkrétním příkladem, ať mají i ostatní šanci zjistit, o čem že to vlastně mluvíš? :)

[Grunt]

BTW: Uživatelé by do svých init skriptů rýpat neměli vůbec. Maximálně tak u Gentoo, kde je předpoklad že tomu uživatel rozumí, určitě ne u binárních distribucí kde má v merku init skripty balíčkovací systém. To je nejčastější případ toho proč se boot rozbije a případná oprava balíčkovacím systémem nepomáhá.

[pavlix]

BTW: Uživatelé by do svých init skriptů rýpat neměli vůbec. Maximálně tak u Gentoo, kde je předpoklad že tomu uživatel rozumí, určitě ne u binárních distribucí kde má v merku init skripty balíčkovací systém.

U Gentoo je to úplně stejné jako všude.

[blami]

Obcas je to ale potreba.

Tohle treba systemd nadherne resi. To co je dorucovano se systemem a za co zodpovida distribuce je v /lib/systemd a uzivatel to muze v /etc/systemd prepalit. Do /etc/systemd ma yum ci jiny balickovaci system vstup zakazan (ale systemova unita se tam muze dostat diky [Install] sekci).

Ja osobne jsem priznivcem systemd presne z toho duvodu, ktery uvadite. Ono to bude ve vysledku velice podobne situaci s PulseAudio, kde se po case ukazalo ze vlastne neni rozbite PulseAudio ale ALSA. Stejne tak se ukaze, ze spousta problemu ktere by se mely resit na urovni kodu demona konkretni sluzby se resi hruzami a hnusy v initskriptu, kde ma tvurce balicku mnohem volnejsi ruce pri tvorbe opravneho prostredku.

[Grunt]

Však jak se nadávalo na GRUB2, když přešel z uživatelem editovatelných konfiguráků na jakýsi skoro polo-binární bastl. Ale všichni maintaineři měly jasno. Míň práce pro ně. Proto je úplně jasné proč se takové věci jako je zavádění, init skripty nebo třeba inicializace zvuku neprovádí pro každou distribuci zvlášť, ale systémově pomocí GRUBu2, systemd a PA. Uživatel nech si hraje na písečku na místech pro to určených a nech do nich netahá ostatní.

[pavlix]

Však jak se nadávalo na GRUB2, když přešel z uživatelem editovatelných konfiguráků na jakýsi skoro polo-binární bastl.

GRUB 2 pokud vím nikdy z uživatelem editovatelných konfiguráků nepřešel. Máš nějaké zprávy o tom, že by se něco takového chystalo?

Spletl sis ho s něčím jiným, nebo převádíš svou nechuť ke GRUBu 2 v úmyslné lži?

[petr_p]

V Gentoo to je udělané jinak (z mého pohledu lépe). Init skript se považuje za konfigurační soubor, takže se dá velmi pohodlně spravovat přes etc-update jako jakýkoliv jiný konfigurák.

[pavlix]

V Gentoo to je udělané jinak (z mého pohledu lépe).

Lépe je to opravdu jen z určitého pohledu. Gentoo má a priori na svého správce podstatně větší nároky než Fedora nebo Debian. To lze vnímat jako daň za mnohé výhody a nebo jako podstatnou nevýhodu.

[petr_p]

Nedávno bylo v Gentoo zapnuto chování config-protect-if-modified, což znamená, že pokud si uživatel konfigurák nezmění, tak se potichu aktualizuje. Takže máte obě výhody najednou.

[----]

protože níže zmíněný důvod a protože Lennart.

[----]

*výše

[mankind_boost]

Gratuluji, teď jste vytvořil nekonečnou smyčku

[Ondroid]

LOL !

[x]

Tady je mnohem zajimavejsi debata k tomutez vcetne zprostredkovanych reakci Linuse, ktery si evidentne o LP a dalsich posucich z RH mysli taky sve Slashdot Gentoo for udev

Taky nevim proc rozbijet tradicni Unix postupy, kdyz je staci jen vylepsit devd(8)

Pripadne kdyz udev, tak proc to neimplementovat logicky udevd(8)

OpenBSD zvlada tyto veci i se statickym /dev doplnene maximalne treba o ifstated pro spravu stavu rozhrani, pripadne hotplugd pro USB a podobne. Nebo snad nekdo menite bezne na serveru nebo i laptopu graficku, cpu a dalsi veci za chodu? Pokud je to high end HW, tak umi hotplug a jsou zde systemy, ktere to umi uz roky i bez udev a funguje to.

A navic mne to matne pripomina, jak se nekdo smal nazoru, ze GPL se pouziva pro boj mezi SW firmama RedHat vyvojar proti firme co vytvorila iSCSI target

[R]

Graficka karta sa bezne za chodu meni, pretoze existuju veci ako USB-VGA, o zvukovke nehovoriac. Rovnako sa menia vsetky mozne ISA/PCI(e) karty, pretoze PCMCIA/CardBus/ExpressCard. Takze staticky /dev je na desktope nepouzitelny.

[x]

Jak casto jste vy a 10 vasich nejblizsich pratel za poslednich 5 let menili grafickou kartu za chodu pocitace? To co ma v nazvu USB uz od podstaty odpovida USB sbernici, kde jsou veci takto odpojitelne uz od prvopocatku a umi to kdejaky OS. Na to neni treba udev.

Uz jste nekdy zkusil za chodu vymenit neco v ISA/PCI slotu? Pravdepodobne jeste ne PCMCIA/CardBus/ExpressCard je trochu neco jineho a opet to umi kdektery OS uz leta i bez udev.

Takze staticky /dev je na desktopu pouzitelny, protoze dynamicky se resi "jinak" jen zarizeni u kterych to ma opravdu smysl. A psat kvuli udev staticke pravidla aby po kazdem restartu byla treba eth0 porad eth0 mne neprijde zrovna jako prinos.

[pavlix]

Takze staticky /dev je na desktopu pouzitelny

Mně nepřijde zrovna OK používat statický /dev na něčem, k čemu se běžně připojují zařízení za běhu. Přece nemůžu předpokládat, co vše může uživatel připojit.

[x]

Ale zarizeni, ktera se pripojuji za behu svuj obecny zaznam v /dev maji uz predtim nez jsou pripojena. Jen pri pripojeni jim jadro priradi ovladac a volne obecne zarizeni jako napr. uadio(4) , ktere uz pak uzivatel ovlada pomoci audioctl/mixerctl. Podobne je to s disky umass(4).

To kam se se pripoji do user space a jak uz je prace neceho jineho (pokud uzivatel vubec chce automaticke pripojeni) jako napr. hotplugd(8) pro USB veci na OpenBSD nebo jine podobne daemony at uz na BSD nebo jinde. Jiste defaultne user mount povoleny neni, ale to je otazkou jednoho sysctl pro admina nebo vlastnika pocitace. Samozrejme, ze neni nutne spolehat na to na kterem konkretnim portu to je nebo bude, protoze je mozne pouzit isduid(3) v /etc/fstab a jinych aplikacich a je pak jedno kam je disk pripojen. Diky tomu (a nejen tomu) je mozny i FDE (Full Disk Encryption) kdy dotazovani na heslo k disku probehne jeste pred samotnym spustenim OpenBSD boot loaderu.

Jen pripominam, ze v tomhle pripade to neni o tom, ze PC nastavuje uzivatel, ktery tomu nerozumi, tomu to ma nastavit nekdo kdo to umi. Bezny uzivatel se nezajima jak to funguje, on chce pracovat a to mu jde umoznit jak na Win, Apple, Linux, tak i BSD. Je to otazka toho jak moc velkou ma nad tim admin kontrolu a jak moc prace s tim musi travit.

[little.owl]

Ano, mate driver pro USB audio, USB mass storage, muzete pouzit i disklabel UID a dokonce i primitivni hot plug deamon. Blahopreji k uspechu!

[x]

Zdaleka to neni vse, ale zajimalo by mne co by teda melo byt dale, kdyz ty "primitivni" veci delaji to co ty preplacane odjinud?

[pavlix]

1) Nevidím důvod mít v /dev hromadu záznamů pro věci, které v mém systému ve skutečnosti vůbec nejsou. Kromě nebetyčného bordelu mi to nic nepřináší.

2) Pokud něco v /dev není a kernel si to najde, nevidím důvod, proč bych to měl do /dev přidávat ručně. Je to hloupé a zbytečné, když o tom zařízení kernel stejně už ví.

Z těchto dvou důvodů preferuju dynamický /dev před statickým. Nepřipadá mi, že by kterýkoli z těch dvou důvodů byl napadnutelný, ani že by existoval nějaký silný důvod proti, se kterým by bylo potřeba tyto důvody vyvažovat.

[little.owl]

Tak OpenBSD jeste tvori zarizeni drevne pres MAKEDEV a mknod a jsou na to pysni, neb je to jediny spravny unixovsky pristup a bordel v /dev je jen detail.

[pavlix]

Chápu. A koneckonců jim to neberu, když to tak chtějí.

[x]

"bordel v /dev" je popis vlastniho pristupu ke sprave systemu predpokladam S tim nepomuze zadny daemon, kdyz clovek co necemu nerozumi hrabe do toho cemu nerozumi a pak si tam udela bordel To konci katastrofou kdekoliv. S tim pristupem jde zaneradit jakykoliv OS na planete

Ten "bordel" je velmi dobre dokumentovan MAKEDEV(8) odkazem z hier(7) a kazde zarizeni v /dev ma svoji manualovou stranku. Chapu, ze vyvojari odvadejici radne svoji praci (to znamena vcetna psani dokumentace pro to co vyvinou) jsou pro jine systemy nadlidsky ukon (nebudeme jmenovat ) a silne nedostatkove zbozi, protoze neustale znovuobjevovat kolo je hlavnim cilem, ale za to ja nemuzu a to si musite holt stezovat jinde

/dev je treba staticky, ale clovek na to vlastne nesaha, protoze tam je vse co potrebuje a tak se ani nemusi starat a to vcetne zbytecneho dalsiho daemona nebo psani skriptu. Jen velmi vyjimecne, kdyz potrebuje neco specialniho, tak pouzije MAKEDEV/mknod, ale to dela admin co vi co dela a proc to dela.

[pavlix]

"bordel v /dev" je popis vlastniho pristupu ke sprave systemu predpokladam S tim nepomuze zadny daemon, kdyz clovek co necemu nerozumi hrabe do toho cemu nerozumi a pak si tam udela bordel To konci katastrofou kdekoliv. S tim pristupem jde zaneradit jakykoliv OS na planete

Hezký pokus :).

[Václav "Darm" Novák]

Díky že systemd v této zprávičce celkem pěkně objasňuješ. Osobně jsem na něj nuceně přešel, ale vím že bude ještě potřeba chvilku studovat. Přínos pro sebe na pracovních stanicích už jsem ovšem poznal (ať už rychlejší boot, nebo přehledná konfigurace) Provozuji Chakru a Arch Linux, na serverech Debian a přechod na systemd by mi vadil jen z jednoho důvodu – předchozí admin psal spoustu konfigurace do init skriptů, takže to budu muset přepsat. Což mě stejně, až mi stávající Debian servery ztratí podporu, čeká…

Stejně si připadám když někdo nadává na pulseaudio – osobně jako člověk, který prostě občas potřebuje za běhu přepínat mezi dvěma zvukovkama a občas připojit i třetí a čtvrtou přes USB (naposledy webkamera s integrovaným mikrofonem a USB headset) a dvakrát využil i síťovou transparentnost PA to vidím jako krok dopředu. O nastavení hlasitosti aplikací zvášť nemluvě. A ne že mi někdo vmete OSS, to je v tragickém stavu.

U bohyně, snažíme se konkurovat jiným OS, tyhle věci jsou krokem dopředu. To že zcela neodpovídají unixové filozofii je sice možné, ale ta je sakra stará a potřebujeme se pohnout dopředu. To co dřív fungovalo skvěle je v novém prostředí otravné. Pro ten zbytek tu budou asi vždy konzervativní alternativy typu slackware, OpenBSD…

[pavlix]

a dvakrát využil i síťovou transparentnost PA

Ve své době jsem chtěl použít PA jako síťový soundserver, tedy jako systémového démona. Na wiki stránce tomu věnované autor psal, že na něco takového PA nebylo nikdy určeno a že mé použití je špatné a že správně ho mám používat jen jako session démona.

To že zcela neodpovídají unixové filozofii je sice možné, ale ta je sakra stará a potřebujeme se pohnout dopředu.

Podle mě bychom měli unixovou filosofii vyvíjet, updatovat, ale ne zatracovat. Tím myslím třeba to, že filesystém /dev je hezká a užitečná věc. Ale statický /dev už je prostě outdated a neodpovídá dnešnímu způsobu práce s počítačem.

[x]

S poslednim bodem souhlas, ale neco jineho je vyvijet a aktulizovat s tim co rika LP, ze jak funguje Unix ho nezajima

"staticky /dev/ je outdated a neodpovida dnesnimu zpusobu prace s pocitacem" - kdyz si koupim laptop, tak nainstaluji OS a to tak klidne zustane nekolik let s tim, ze tam nic moc zmenit nemuzu a co muzu pripojovat (USB, PCMCIA, RJ-45, SD/MMC,...) jde pripojovat jednoduse i bez udev a to i automaticky, to same server, ten taky nikdo jen tak z nudy co tyden neobstastni novymi komponenty, ba naopak to klidne bezi 5 let ve stejne konfiguraci a absolutne nic se s tim nedeje a to ani pres USB, protoze se leze pres ILO a podobne, ze to ma neco hotswap, tak to jde vymenovat take bez udev nebo podobneho demona a kdyz jsme u toho, tak desktop je uplne to same. Je vzdycky legracni, kdyz se udev obhajuje stylem jak kdyby kdekdo vcetne nejvetsich guru menil co 5 minut za chodu OS grafiku, CPU, desku a jine veci v pocitaci, asi vetsina vi, jak casta a pravdepodobna je to udalost, k tomu jsou opet USB, IEEE-1394, BT a jine veci, ktere ale opet jsou davno resitelne i bez udev.

Myslim to naprosto vazne a rad bych vedel konkretni priklady v cem VYRAZNE udev prispel oproti statickemu /dev a hlavne POCETNI vyuziti za poslednich 5 let. Bylo by to moc zajimave jestli se to opravdu pouziva nebo to proste jen bezi, ale realne to nic "nedela". Priklady jako nucene nastavovani udev pravidel na serveru, ktery ma 5 sitovek aby po kazdem reboot nemela nektera z nich jine cislo nez predtim a mne tak neprestali fungovat nastavovaci skripty nepocitam za prinos, je to zbytecny daemon navic bezici na serveru, navic komplikujici administraci a nastaveni, protoze tyhle stavy se pred udev nedeli ani na Linuxu.

[pavlix]

Já nevím, jestli si rozumíme. Když držím v ruce flashku, tak necítím důvod, aby byla vidět v /dev. Když ji zapojím do počítače, tak už ten důvod cítím. A nemusí to být flashka, může to být USB zvukovka, USB grafárna, USB cokoli. To stejné platí i pro jiné hotplug věci než USB, ale i pro věci, které se mění při vypnutém stroji.

Pravidla pro udev se reálně využívají, a to jak vestavěná, tak administrativně změněná. A nenastavují pouze jméno ve filesystému a symlinky, ale hromadu dalších věcí včetně vlastnictví a oprávnění.

Dokonce i tu údržba stejných jmen pro stejná síťová rozhraní mnozí považují za klíčovou vlastnost a naprosto je chápu. Tvrzení, že problém neexistuje ještě nikdy problém nevyřešilo :).

Já neříkám, že je udev kdovíjak skvělá věc, ale pokud by se ze dne na den z linuxového světa vytratí, tak mu bude sakra chybět. Možnosti, které udev nabízí jsou každodenně používané a musely by se buď nahradit nebo oželet.

Je nesmysl nahlížet na Linux jako pouhou alternativu k OpenBSD. Linux se používá v mnohých prostředí, kde se OpenBSD nepoužívá. Fungují na něm jiné způsoby a zvyklosti.

Myslim to naprosto vazne a rad bych vedel konkretni priklady v cem VYRAZNE udev prispel oproti statickemu /dev a hlavne POCETNI vyuziti za poslednich 5 let.

Početní využití je denně na hromadě strojů na světě, takže na to doufám podrobněji odpovídat nemusím. A výrazné přispění oproti statickému /dev je už i v tom, že /dev může obsahovat seznam zařízení v počítači místo seznamu zařízení, které by kernel zvládl teoreticky naadresovat.

Statický /dev považuju za věc natolik odkloněnou od reálného (dynamického) světa počítačů, že je vůbec nemůžu pojmout myšlenku, že by mohl být dnes reálnou alternativou k dynamickému.

[x]

Ano, ale jako uzivatele mne nezajima co se deje v pocitaci, kdyz nejakou z tech veci pripojim. Chci aby zafungovala a je jedno jak. Jako administratoru mi to jedno neni a chci mit nad tim kontrolu a co nejmene zbytecne prace.

Jenze problem udrzby stejnych jmen pro stejna rozhrani pred udev prakticky neexistoval a naopak ho prinesl udev, takze pouzivat to za klicovou vlastnost je minimalne usmevne. Klicovy bug mozna. V letech pred udev jsem na Linuxu tento problem resit nemusel vubec na serverech ani jednou jedinkrat. Od doby udev bohuzel az prilis casto. Nepovazoval bych to za ulehceni prace venovat se necemu cemu jsem predtim nemusel.

Linux zcela jiste neni alternativa k OpenBSD a v podstate i obracene vzhledem ke zcela jinym zamerenim projektu. To je logicke a neni na tom vubec nic spatneho. Od toho je tady open source a moznost vyberu.

Kdyz je ten svet tak dynamicky, tak proc nevyhodit treba slovo static z C? Chtel bych videt jak dlouho by ta dynamika vydrzela, pokud by EU opravdu zavedla odpovednost SW vyrobcu za chyby v SW Ze je neco dynamicke neznamena, ze vsechno okolo musi byt za kazdou cenu taky dynamicke. Ono kdysi davno si taky vetsina myslela, ze Zeme je placata a byl to "mainstream" nazor, ale ukazal se taky jako spatny.

[pavlix]

IMHO LOL

Ale rozhodně oceňuji tvoji fantazii a výřečnost.

[jyrki]

Promin ale s tim ze udev nebylo posunem, ale pritezi pro normalni uzivatele ma absolutni pravdu. Je neskutecne iritujici kdyz se mi prohazuji sitovka mezi bootama a clovek pak musi psat debilni udev pravidlo. Ja proste ocekavam ze to bude fungovat a bude to fungovat porad stejne. A jako uzivateli mi udev neprineslo, mimo vyse zminenych problemu, nic navic.
A se systemd je to naprosto stejne.

[little.owl]

Jake mate sitovky?

[jyrki]

Momentálně tyto:
[ 21.468701] 8139too 0000:01:09.0: eth0: RealTek RTL8139 at 0xffffc90010fb8c00, 00:50:fc:80:dc:d9, IRQ 19
[ 21.476084] systemd-udevd[6921]: renamed network interface eth0 to net0
[ 21.747727] r8169 0000:04:00.0: eth0: RTL8102e at 0xffffc90000658000, 6c:62:6d:83:a2:42, XID 04c00000 IRQ 43
[ 21.756079] systemd-udevd[6923]: renamed network interface eth0 to net1
Ale to neni podstatne, udev mi prohazoval sitova zarizeni at byla jakakoliv a kdyz jich bylo vice nez dve, bylo to jeste "zabavnejsi". Podobne chovani jsem nezazil na starem Linuxu nebo jakemkoliv BSD. Opravdu posun vpred...

[little.owl]

Jste sto let za opicemi. Here ci here.

Co mate za OS? Fedora a RHEL/CentOS to uz davno maji.

[jyrki]

Momentalne Sabayon Linux.
Pak je tedy prakticky kazda Linux distribuce sto let za opicemi

[little.owl]

Pak se spise zeptejte maintaineru, proc nepouzili, kdyz tu moznost pres dva roky maji.

[x]

Ja bych s tema opicema hodne opatrne, protoze pri pohledu na stranku Fedora NetworkManager jsem se malem potrhal smichy co vsechno to neumi, co je rozbite a co se teprve planuje, kdyz jinde tyhle veci jsou davno.

Fedora - Alpha verze jsou vetsine lidi k nicemu a ne nadarmo se hodne lidi drzi i nekolik verzi zpet.

RHEL - dost nepouzitelne bez podpory

CentOS - vcelku fajn, ale jsou nejaci pomalejsi s aktualizacema. Lepsi uz je ScientificLinux.

Ale Linux neni jen RedHat a jeho klony. To zavani tak trochu MS pristupem ze my mame to nej a vy ostatni jste k nicemu

[little.owl]

Tady je krasne videt jak placate.

CentOS ma aktualizace rychle, rychlejsi nez Scientific Linux, jen prvni verze po prichodu major verze neni uvolnena rychle dokud neni v poradku potrebna infrastruktura. Ale jak to vyjde, nikdo neni bez security updatu ode dne jedna.

Na Fedore jedu od sameho pocatku (Fedora Core 1) a jsou s ni asi tak 100 x mensi problemy nez s OpenBSD.

[jyrki]

Na Fedore jedu od sameho pocatku (Fedora Core 1) a jsou s ni asi tak 100 x mensi problemy nez s OpenBSD.

Hloupy argument. Muzu vratit podobnou minci, Arch byl naprosto bezproblemove distro dokud nezacal prejimat veci z Fedory. Diky tomu zacal odliv uzivatel.

[little.owl]

Arch byl naprosto bezproblemove distro dokud nezacal prejimat veci z Fedory. Diky tomu zacal odliv uzivatel.

Veci z Fedory prejimaji od sveho vzniku, na tom neni vubec nic noveho, ostatne jako temer jako kazda jina distribuce.

Ale jen casto to neumi poradne naintegrovat/otestovat, a pak je to "zabugovane" a clovek se musi smat jak je mozne, ze to co mi uz chodi dva roky, jinde ani neznaji.

[little.owl]

stranku Fedora NetworkManager jsem se malem potrhal smichy co vsechno to neumi,

Vy si ale koledujete .

[pavlix]

stranku Fedora NetworkManager jsem se malem potrhal smichy co vsechno to neumi,

Vy si ale koledujete .

Já mu hlavu neutrhnu. Dlouho jsem čekal, kdo mi jako první dá sežrat, že se snažím sepisovat skutečné informace a prezentovat věci tak, jak jsou :).

[x]

Omyl Tuhle cast velmi chvalim, protoze je to dobre odvedena prace. Ja se trhal smichy nad tim, co NM porad neumi, ne nad kvalitou te stranky, ktera je velmi dobra. Je jen velmi smutne, ze RH tohle nezaridil hned ze zacatku, ale to je obecny problem urovne vyvoje v jakekoliv firme nebo open source projektu (vetsine z nich), proste tristni pristup a dokud se nenajde jeden, tak to neudela nikdo. V komunite kde to lidi delaji jako konicek budiz, ale u systemu, ktery ma nejaka firma jako svoje testovaci prostredi.......

[pavlix]

Beru.

[pavlix]

A víš co. Já jsem rád, že na to došlo. Alespoň vím, že ta práce má smysl, a že si moje plky na Fedoří wiki taky někdo přečte. A zdaleka ne jen lidi z Red Hatu či Fedory.

[little.owl]

Ja jsem to videl poprve pred par dny a ocenil, a stejne tak moji kolegove. Prvni krok k naprave je dokumentace problemu, takze mas dobre nakroceno. Ostatne tahle situace neni zas tak neobvykla, zadne problemy casto znamenaji zadne testovani. Ja obcas nenavidim nase testery, kdyz mi prijdou ukazat, co jsem zase nedomyslel.

[pavlix]

Teď řeším s našimi lidmi getaddrinfo() a musím říct, že je to tvrdý boj. Vždy se najde nejmíň pět špatných workaroundů, které danou chybu „schovají“.

Ostatně, jednou z hlavních věcí, na které teď dělám je testovatelnost.

[pavlix]

Ja bych s tema opicema hodne opatrne, protoze pri pohledu na stranku Fedora NetworkManager jsem se malem potrhal smichy co vsechno to neumi, co je rozbite a co se teprve planuje

Tu stránku jsem sepisoval já osobně jakožto vývojář NetworkManageru, aby byl přehled o tom, jak to skutečně je.

kdyz jinde tyhle veci jsou davno.

Zjišťoval jsem si informace a žádný network démon, na kterého jsem narazil jaksi na NetworkManager nemá. Byla o tom řeč v Praze na LinuxDays, kde jsme měli i moderovanou debatu s vývojáři Wicked.

Nemám žádné zprávy o tom, že by kdo na *BSD provozoval třeba démona, který zvládá automatickou konfiguraci IPv6, a to není zdaleka všechno, co v tuto chvíli NetworkManager umožňuje.

Ve své době chtěli NetworkManager portovat na FreeBSD, aby se i tam dotáhla funkcionalita, která tam tak trochu chybí, ale z důvodu návrhu NetworkManageru to moc nešlo.

[Václav "Darm" Novák]

Připojím síťovku, automaticky se zapíše nové pravidlo, dostane jméno. Připojím jinou, dostane nové jméno.

Vše staticky nadefinováno v pravidlech udev a zcela automatický. Arch Linux, Debian stable, Chakra. Problém je tedy asi jinde :)

[little.owl]

Ja povazuji za velkou vyhodu, ze pohledem do /dev zjistim, jaka zarizeni jsou pritomna, stejne jako konzistentni [a perzistentni] pojmenovani. Navic mam k dispozici API, ktere umozni me aplikaci rozumne zjistit co je vlastne pripojeno a jake to ma vlastnosti. Tady nejde totiz jen o pohodli uzivatele - ale i o usnadneni prace vyvojarum - pak se proste nedivte ze na vas vyvojari desktopovych prostredi kaslou, kdyz jim nechcete usnadnit praci.

[x]

Tak to pohledem do /dev nezjistim ani omylem ktera zarizeni jsou realne pritomna pri bezicim udev

# ls -F asm/ dm-14 dm-33 indc mpath/ ram1 rtc sdar sdbj sdg sdz sg25 sg42 sg6 sg9 tty19 tty36 tty53 urandom vcs3 autofs dm-15 dm-34 initctl| net/ ram10 sda sdas sdbk sdh sg0 sg26 sg43 sg60 shm/ tty2 tty37 tty54 usbdev1.1_ep00 vcs4 bus/ dm-16 dm-35 input/ null ram11 sdaa sdat sdbl sdi sg1 sg27 sg44 sg61 snapshot tty20 tty38 tty55 usbdev1.1_ep81 vcs5 casr dm-17 dm-36 js0@ null0 ram12 sdab sdau sdbm sdj sg10 sg28 sg45 sg62 stderr@ tty21 tty39 tty56 usbdev2.1_ep00 vcs6 cciss/ dm-18 dm-37 kmsg nvram ram13 sdac sdav sdbn sdk sg11 sg29 sg46 sg63 stdin@ tty22 tty4 tty57 usbdev2.1_ep81 vcsa ccsm dm-19 dm-38 log= ofsctl ram14 sdad sdaw sdbo sdl sg12 sg3 sg47 sg64 stdout@ tty23 tty40 tty58 usbdev3.1_ep00 vcsa1 cdt dm-20 dm-39 loop0 oldmem ram15 sdae sdax sdbp sdm sg13 sg30 sg48 sg65 systty tty24 tty41 tty59 usbdev3.1_ep81 vcsa2 cecc dm-21 dm-40 loop1 oracleasm/ ram2 sdaf sday sdbq sdn sg14 sg31 sg49 sg66 tty tty25 tty42 tty6 usbdev4.1_ep00 vcsa3 cevt dm-22 dm-42 loop2 parport0 ram3 sdag sdaz sdbr sdo sg15 sg32 sg5 sg67 tty0 tty26 tty43 tty60 usbdev4.1_ep81 vcsa4 console dm-23 dm-43 loop3 parport1 ram4 sdah sdb sdbs sdp sg16 sg33 sg50 sg68 tty1 tty27 tty44 tty61 usbdev5.1_ep00 vcsa5 core@ dm-24 dm-44 loop4 parport2 ram5 sdai sdba sdbt sdq sg17 sg34 sg51 sg69 tty10 tty28 tty45 tty62 usbdev5.1_ep81 vcsa6 cpqhealth/ dm-25 dm-6 loop5 parport3 ram6 sdaj sdbb sdbu sdr sg18 sg35 sg52 sg7 tty11 tty29 tty46 tty63 usbdev6.1_ep00 VGu02/ cpu/ dm-26 dm-7 loop6 port ram7 sdak sdbc sdbv sds sg19 sg36 sg53 sg70 tty12 tty3 tty47 tty7 usbdev6.1_ep81 VolGroup00/ crom dm-27 dm-8 loop7 ppp ram8 sdal sdbd sdbw sdt sg2 sg37 sg54 sg71 tty13 tty30 tty48 tty8 usbdev6.2_ep00 X0R@ disk/ dm-28 dm-9 MAKEDEV@ proc ram9 sdam sdbe sdbx sdu sg20 sg38 sg55 sg72 tty14 tty31 tty49 tty9 usbdev6.2_ep81 zero dm-10 dm-29 fd@ mapper/ ptmx ramdisk@ sdan sdbf sdc sdv sg21 sg39 sg56 sg73 tty15 tty32 tty5 ttyS0 usbdev6.2_ep82 dm-11 dm-30 full mcelog pts/ random sdao sdbg sdd sdw sg22 sg4 sg57 sg74 tty16 tty33 tty50 ttyS1 vcs dm-12 dm-31 hpet md0 ram@ rawctl sdap sdbh sde sdx sg23 sg40 sg58 sg75 tty17 tty34 tty51 ttyS2 vcs1 dm-13 dm-32 hpilo/ mem ram0 root sdaq sdbi sdf sdy sg24 sg41 sg59 sg8 tty18 tty35 tty52 ttyS3 vcs2

Zkusebne man casr, ccsm, loop, rawctl, dm(obzvlaste vtipne) ani jedno nema manualovou stranku. Z nazvu jakztakz neco mohu odvodit, ale to mohu snadno i na BSD. Tam to ma ale navic manualovou stranku kde se dozvim co a k cemu to je a dalsi odkazy cim to treba nastavit.

Ktere konzistenti API pro zjistovani informaci mate na mysli? /proc filesystem? ls -F /proc je jeste horsi pohled nez ls -F /dev , ale neco se tam najit da. Na druhou stranu na BSD je dmesg stale perfektne citelny a jednoduchy pro info o tom co je v PC (/var/run/dmesg.boot pro verzi pri startu bez pridani veci nasledne za chodu). Kdyz udelam sysctl hw.disknames, tak je to jeden ze zpusobu jak zjistit co mam v PC pak muzu jit treba man sd, ioctl, scsci, fdisk, disklable atd. az do systemovych volani, knihovnich funkci a spoustu dalsiho co je poradne dokumentovano vyvojari, protoze ti to potrebuji, tak je jejich prace aby to usnadnili i dalsim vyvojarum. Pro uzivatele jsou tady veci jako usbdevs (lsusb), pcidump (lspci), acpidump atd. pro reportovani vyvojarum nejakych detailu.

Vyvojari Gnome kaslou i na Linux, ale Linux zacina kaslat na ne a uzivatele taky State of Gnome, firmy co prispivali sli pryc taky. Nekteri vyvojari utikaji taky . Ale jinak to RH vede dobre na Fedore a problem bude zcela jiste v BSD a ne Gnome/RH a protoze BSD ma problem, tak se to posledni dobou vsude resi? Vyvojari desktop prostredi potrebuji uzivatele a proto na BSD nekaslou, napr. KDE velmi dobre spolupracuje s BSD stejne jako mnozi dalsi. Gnome/RH/Fedora si sni svuj sen, ktery zacina i Linux uzivatele dost vytacet. Vymlouvat se na BSD je usmevne. BSD ma zajem byt na desktopu a je z ceho vybirat. Klidne i Gnome, ale pokud se z nej stane umyslne Gnome OS nefungujici poradne ani na Linuxu, tak jaky by melo smysl to podporovat?

[little.owl]

To je argument - vyexportovat dynamickou adresarovou strukturu a rici, ze je to neprehledne. Zarizeni je v PC plno a proto je tam toho tolik a dynamicky dev to naopak zjednodusuje.

[x]

Vy jste tvrdil, ze pohledem do /dev jde zjistit co je aktualne pouzivano, ale jak vidno, tak i s udev to vypada porad stejne a dokonce tam jsou veci, ktere realne na serveru nejsou. Kdepak soudruzi udelali chybu? Pri tolika davkach chvaly na udev bych cekal, ze se ten nastroj postara o to, at v tom /dev je opravdu jen to co existuje Vzdyt prece staticky pristup je tak zastaraly

[little.owl]

Ktere konzistenti API pro zjistovani informaci mate na mysli? /proc filesystem?

Napriklad libudev.

jde zjistit co je aktualne pouzivano

Ne, to jsem nerekl.

ktere realne na serveru nejsou

udev vam umoznuje vytvorit a pouzivat i staticke device a pak tu mate virtualni device.

[x]

# man libudev No manual entry for libudev #

Fakt takovy strasny problem tohle dat do libudev(3)?

V mem vystupu nejsou zadne staticke device vytvorene. Virtualni bych napred musel mit jednoduchy zpusob zjistit ktere to jsou. Jiste nektere znam, ale mohou tam byt dalsi, ktere neznam, man stranku to nema a hledat do na webu je pro mne ztrata casu dost casto, protoze clovek velmi casto narazi na zastarele informace. To je problem toho "Mame Internet, proc psat dokumentaci".

[pavlix]

Příloha:

• dev-directory.png (62538 bytů)

To abychom se bavili když už tak o tom, jak to skutečně vypadá (viz příloha). Velké množství souborů tty* jsou právě pozůstatkem statického přístupu, stejně jako některé další.

[jyrki]

Velké množství souborů tty* jsou právě pozůstatkem statického přístupu, stejně jako některé další.

Kdyz uz tedy neco menili, tak proc to neudelali poradne a nedotahli? Opet je to jen dalsi nedodelek ktery zustal nekde napul cesty.

[little.owl]

Ne. To nemuzete udelat najednout pokud je spousta SW, ktery to jeste potrebuje. Dela se to postupne, ale dela se to a chce to svuj cas.

[jyrki]

Pak to meli drzet v testing vetvych a ne poustet do produkce.

[little.owl]

Proc? Vzdy to funguje. Proste to bude podporovano o neco dele.

[jyrki]

Muzete jeste zodpovedet dotaz x ohledne dokumentace k jednotlivym devices? Ten by me totiz skutecne zajimal. To ze to funguje neni uplne to podstatne, to je jaksi samozrejmost, spise jde o ten prinos. Vznik udev listopad 2003, v roce 2010 to umelo konzistentni pojmenovani devices, dokumentace k devices jeste v listopadu 2012 chybi a konzistejntni pojmenovani neni zavedeno napric distribucemi (neznalost, spatna dokumentace)? A tolik predhazovane vyhody, totiz ze /dev bude obsahovat jen to co v PC skutecne je, jeste neplati a chce to cas. Neni neco spatne?

[little.owl]

Vznik udev listopad 2003, v roce 2010 to umelo konzistentni pojmenovani devices

Jen jste si musel napsat prislusne rules.

dokumentace k devices jeste v listopadu 2012

Jak Fedora, tak RHEL to maji dokumentovane od zacatku. Zacnete treba referencnimi manualy RHELu.

konzistejntni pojmenovani neni zavedeno napric distribucemi (neznalost, spatna dokumentace)?

To je problem jednotlivych distribuci, Fedora sve features deklaruje 6 mesicu dopredu a byl toho plny web.

[jyrki]

Jen jste si musel napsat prislusne rules.

Presne tohle mi vadi. Nic navic krome problemu a hledani workaroundu.

Jak Fedora, tak RHEL to maji dokumentovane od zacatku. Zacnete treba referencnimi manualy RHELu.

Uz zminene casr, ccsm, loop, rawctl, dm - dokumentace je kde?

To je problem jednotlivych distribuci, Fedora sve features deklaruje 6 mesicu dopredu a byl toho plny web.

To je cast toho problemu. Trvalo to prakticky 7 let nez se s udev default nastavenim zasahu admin dokazali vratit k funkcionalite pred rokem 2003?

[little.owl]

Nic navic krome problemu a hledani workaroundu.

Udev rules jsou jen konfiguracni soubor jako kazdy jiny.

Uz zminene casr, ccsm, loop, rawctl, dm - dokumentace je kde?

Man pages a referencni manualy. Dokumentace dodavana se zdrojovymi balicky, ostatne i zdrojove kody. Tohle jsou low level veci vyzadujici slusnou znalost systemu a stejne jako u cehokoliv pokrocilejsiho je doba k nauceni dlouha. Pokud chcete uceleny studijny material, pak i zde se vyplati nelitat po netu a skladat utrzky informaci, ale koupit si knihy. Ostatne on i Red Hat nevydelava na kurzech a certifikacich zas tak nahodou.

Trvalo to prakticky 7 let nez se s udev default nastavenim zasahu admin dokazali vratit k funkcionalite pred rokem 2003?

Nestraste, pred 2003 bych se vratit v tomhle nechtel. To ze to bylo predtim vyreseno byla v rade pripadu jen virtualni iluze. Jak chcete treba u USB sitovek zajistit aby mapovaly stale ve stejnem poradi, kdyz startuji v nahodne posloupnosti, pricemz poradi urcuje minor cislo a to bez navazujicici vyssi logiky?

[little.owl]

OK, chapu kam mirite, rozhodl jsem se, ze vas uplne nevyignoruji, byt mi to da praci.

Zakladni zarizeni maji standardni naming konvenci, tady se linux nelisi od ostatnich systemu (lp - printer, sd/hd disky, tty terminal etc.). Pak mate pseudozarizeni jako /dev/null, /dev/random a par dalsich. Dalsi identifikatory jsou exportovana drivery jednotlivych zarizeni nebo subsystemy (device mapper). Co je to, muzete zjistit treba pomoci prikazu udevadm:

udevadm info -q path -n /dev/hidraw0
/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.3/1-5.3:1.0/0003:046D:C52E.000D/hidraw/hidraw0

Z toho lze vycist topologii - kde a jak je to pripojeno - zde pres PCI na USB, vcetne id, portu a slotu.

Informace o driveru, pripojne sbernici etc., ze /sys/:

tree /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.3/1-5.3:1.0/0003:046D:C52E.000D/hidraw/hidraw0
/sys/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.3/1-5.3:1.0/0003:046D:C52E.000D/hidraw/hidraw0
|-- dev
|-- device -> ../../../0003:046D:C52E.000D
|-- power
|   |-- async
|   |-- autosuspend_delay_ms
|   |-- control
|   |-- runtime_active_kids
|   |-- runtime_active_time
|   |-- runtime_enabled
|   |-- runtime_status
|   |-- runtime_suspended_time
|   `-- runtime_usage
|-- subsystem -> ../../../../../../../../../../class/hidraw
`-- uevent

Zde vidite, ze driver je hidraw a dokumentaci lze nalezt zde a zde, nebo primo v nainstalovane dokumentaci kernelu. U rady driveru necekejte lehkou odpoved.

Dluzite mi pet minut spanku.

[x]

Konecne se nekam dostavame. Vystup z udevadm toho bohuzel moc neosvetluje a neni moc citelny pro vetsinu lidi. Taky ne az tolik lidi muze vedet co je HID a co je RAW a kam by jejich spojeni mohlo mirit. Ale je to aspon neco.

Nicmene co povazuji za opravdu zabavne vzhledem k vasemu objahovani RH je to, ze davate odkaz na dokumentaci nekam uplne mimo RH. Navic na serveru treba bezne neni hned dostupna sit ven a tak mi takovy odkaz je docela k nicemu, kdyz resim neco na serveru A taky kdyz se divam do Linuxu, tak 'man usb', 'man hid', 'man hidraw' nevraci vubec nic a treba pro admina co s tim nedela casto a pracuje s vice OS je to fakt "prinosne" litat nekde po webu, kdyz to ma byt v systemu primo od vyvojaru. Viz.

uhidev(4)

uhid(4)

usb(4)

bluetooth(4)

Atd. atd. Toto jsou veci co pomahi vyvojarum, adminum a i beznym uzivatelum (pokud se o to zajimaji). Kdyz se mi rozsype pripojeni k Internetu, tak je hezke, ze najdu dokumentaci na Internetu, ale to je mi v tu chvili platne jak mrtvemu zimnik.

[little.owl]

Vystup z udevadm toho bohuzel moc neosvetluje a neni moc citelny pro vetsinu lidi.

Je citelny pro kazdeho, kdo vi cosi o kernel driver modelu.

k vasemu objahovani RH

Kde?

ze davate odkaz na dokumentaci nekam uplne mimo RH.

Mozna jste si ani po letech nevsiml, ale Linux kernel je online projekt sdileny mezi distribucemi. Opet stary argument - Linux neni OS, ale "jen" kernel, ze.

A taky kdyz se divam do Linuxu, tak 'man usb', 'man hid', 'man hidraw' nevraci vubec nic a treba pro admina co s tim nedela casto a pracuje s vice OS je to fakt "prinosne" litat nekde po webu, kdyz to ma byt v systemu primo od vyvojaru.

Dokumentace kernelu v Linuxu nema tradicne formou man stranek a ve vetsine distribuci se instaluje jako samostany balicek. Nic noveho. Co je hlavni, pro zajemce o danou problematiku je k dispozici cela rada [i volne dostupnych] knih. O architektukture kernelu a driveru najde mnohem vice zdroju nez u *BSD, od zacatecniku po pokrocile, nemluve o zivejsich [i specializovanych] mailing listech.

pro admina

Pokud admin na OpenBSD potrebuje studovat drivery, aby zajistil zakladni funkcionalitu, je to spise jen smutne, a co vice, podle dostupnych benchmarku mu to ani nepomuze.

Extremne zdokumentovany bobek je stale bobek. Zacinate se uchylovat k argumentaci, kterou jiz slycham patnact let a cas ukazal, ze je v praxi naprosto irelevantni.

[x]

A ja myslel, ze jeden z duvodu pro udev je usnadneni administrace a prace se systemem, do cehoz ja pocitam tedy i srozumitelnost bez nutnosti dlouhodobeho studovani. Ale vida, ono je k tomu potreba i dalsi low level znalosti. Pravda, nac mit tohle:

$ usbdevs -dv -a 2 -f /dev/usb5 Controller /dev/usb5: addr 2: low speed, power 100 mA, config 1, DELL Laser Mouse(0x4d51), Primax Electronics(0x0461), rev 7.17 uhidev1 $

nebo tohle:

$ usbctl -a 2 -f /dev/usb5 | more DEVICE addr 2 DEVICE descriptor: bLength=18 bDescriptorType=device(1) bcdUSB=2.00 bDeviceClass=0 bDeviceSubClass=0 bDeviceProtocol=0 bMaxPacketSize=8 idVendor=0x0461 idProduct=0x4d51 bcdDevice=717 iManufacturer=0() iProduct=2(DELL Laser Mouse) iSerialNumber=0() bNumConfigurations=1

CONFIGURATION descriptor 0: bLength=9 bDescriptorType=config(2) wTotalLength=34 bNumInterface=1 bConfigurationValue=1 iConfiguration=0() bmAttributes=a0 bMaxPower=100 mA

INTERFACE descriptor 0: bLength=9 bDescriptorType=interface(4) bInterfaceNumber=0 bAlternateSetting=0 bNumEndpoints=1 bInterfaceClass=3 bInterfaceSubClass=1 bInterfaceProtocol=2 iInterface=0()

HID descriptor: bLength=9 bDescriptorType=cs_device(33) bcdHID=1.11 bCountryCode=0 bNumDescriptors=1 bDescriptorType[0]=cs_config(34), wDescriptorLength[0]=64

Report descriptor Usage Page(1) Usage(2) Collection (Application) Usage(1) Collection (Physical) Usage Page(9) Usage Min(1) Usage Max(5) Logical Min(0) Logical Max(1) Report count(5) Report size(1) Input (Data, Variable, Absolute, No wrap, Linear, Preferred state, No null position, Bit field) Report count(1) Report size(3) Input (Constant, Variable, Absolute, No wrap, Linear, Preferred state, No null position, Bit field) Usage Page(1) Usage(48) Usage(49) Logical Min(63489) Logical Max(2047) Report size(12) Report count(2) Input (Data, Variable, Relative, No wrap, Linear, Preferred state, No null position, Bit field) Usage(56) Logical Min(129) Logical Max(127) Report size(8) Report count(1) Input (Data, Variable, Relative, No wrap, Linear, Preferred state, No null position, Bit field) End Collection End Collection

ENDPOINT descriptor: bLength=7 bDescriptorType=endpoint(5) bEndpointAddress=1-in bmAttributes=interrupt wMaxPacketSize=5 bInterval=10

current configuration 1

---------- $

kdyz si to jde prodlouzit.

To neni pro mne nic noveho jakym zpusobem se vyviji kernel, ale to mela byt vymluva na chybejici dokumentaci nebo poukazani na to, ze distribuce nejsou schopne se dohodnout na vytvoreni dokumentace?

LOL - "O architektukture kernelu a driveru najde mnohem vice zdroju nez u *BSD", BSD to ma pochopitelne v man strankach, knihy jsou take, dale hromady prezentaci a technickych dokumentu z BSD konferenci, mailing listy atd.

Ze Linux "tradicne" nepouziva man stranky bych se zrovna moc nechlubil Svedci to pristupu mnohem vice nez je zdravo. Neco jako , ze?

Nevim proc by mel admin studovat drivery, ale obcas si to prectu, protoze to je zdokumentovane a stejne je nuda, kdyz vsechno jede jak ma, tak nejak ten cas clovek zabit musi Vidim, ze argumenty dochazi a zacinaji se vytahovat benchmarky Pravdepodobne ten hodne stary z roku 2003 nebo ty "povedene" z Moronix? PostgreSQL, Desktop, multimeda, MySQL, email server, web server (Apache, nginx), firewall/router (bez problemu 40Gb) zadny problem, NFS na 1Gb siti lehce pres 100MB/s atd. Proste nuda. Jiste, o neco pomalejsi to bude vzdy diky tomu kde vsude uvnitr systemu je implementovano silne sigrovani a vyuziti random generatoru a to by default, na jinych OS se to casto musi zapinat. Je to otazka vyberu, jestli chce clovek stabilni o neco pomalejsi system, ktery zvladne moderni praci i na starsim HW nebo chce neco fungujici rychlosti svetla, ale i tak casto a rychle to doleti do kytek

[David Jaša]

O lsusb jsi už slyšel?

[little.owl]

Vy jste usmevny.

Vas vypis z hlediska informaci neni ekvivaletni tomu co jsem uvadel k dotazu souvisejicim s dev/udev. Obdobna funkcionalita specificka pro USB je v Linuxu zajistena jiny nastroji, napriklad zname lsusb snad netreba zminovat.

Ze Linux "tradicne" nepouziva man stranky bych se zrovna moc nechlubil

Nic takoveho jsem nerekl, opet vase dalsi dezinterpretace. Psal jsem:

Dokumentace kernelu v Linuxu nema tradicne formou man stranek a ve vetsine distribuci se instaluje jako samostany balicek.

A to jste me obvinil nekolikrat z neschopnosti analyzovat psany text.

jestli chce clovek stabilni o neco pomalejsi system, ktery zvladne moderni praci i na starsim HW

LOL. Asi si koupim v bazaru nejaky stary srot, aby si to mohl konecne vyzkouset, KVM neni ono.

[x]

udev zacal v roce 2003, na mem vystupu nebo obrazku je hromada zarizeni, ktere nejsou v systemu a ne, opravdu se nejedna o tty. Ty snad vime tady vsichni k cemu jsou. Takze kde to vazne s tolika tisicovkama vyvojaru a hromadou firem co prispivaji na rozvoj? Tam uz mel byt prece davno poradek a zobrazovano jen to co opravdu na serveru je.

Take si vsimam, ze taktne je pomlceno od vsech o me poznamce o tom kde je popis tech jednotlivych zarizeni v man nebo jak u nekterych s prapodivnymi nazvy poznam co to je. To za 9 let ty hromady lidi taky neumi dokumentovat? To je ale dost smutny pribeh. Asi jako ifconfig, ktery se na Linuxu nahrazuje od roku 1999 pomoci iproute2, ale dopadlo to tak, ze ifconfig se nevyviji, ale vsichni to pouzivaji a takova man stranka od ip to je posusnanicko. Tim naznacuji, ze kdyz uz neco, tak radeji mene, ale poradne nez se snazit o kdeco a vysledkem je hruza.

[pavlix]

Takze kde to vazne s tolika tisicovkama vyvojaru a hromadou firem co prispivaji na rozvoj? Tam uz mel byt prece davno poradek a zobrazovano jen to co opravdu na serveru je.

Jo tak odtud vítr vane. Já bych se někdy chtěl bavit s těmi ostatními BSDčkáři. Tedy s těmi normálními přátelskými lidmi, jejichž diskuze není řízená závistí.

a takova man stranka od ip to je posusnanicko

Manuálové stránky. Ne manuálová stránka. Od března tohoto roku vypadá dokumentace k příkazu ip podstatně jinak.

Tim naznacuji, ze kdyz uz neco, tak radeji mene, ale poradne nez se snazit o kdeco a vysledkem je hruza.

Kritizovat z venku je sice možná příjemné a naplňuje to ego, nicméně mě spíš baví kritizovat zevnitř. Protože když kritizuju zevnitř, tak to dělám proto, aby se projekty, které používám nebo se na nich podílím, zlepšovaly. Ne proto, abych si nahonil ego.

Ale každému, co jeho jest. Kdybys takovýhle elán do nadávání na linux použil ve formě konstruktivní kritiky, ideálně na projekt, který tě skutečně zajímá, a ještě k té kritice občas přidal trochu toho kódu, tak bychom se mohli bavit na úplně jiné úrovni.

[x]

Ja se bavim uplne normalne. Jen nemam potrebu si nechat omlatit o hlavu nesmysly jako vyvojari z RedHat rikaji, ze nemaji lidi delat BSD a radeji jit delat Linux a podobne. Bavime se tady celou dobu o konkretnich problemech, potvrzuji je i jini Linux uzivatele, je to videt i z ruznych clanku od vyvojaru Linux systemu, Slashdot, The Register a hromady dalsich. Ale nekteri budou porad mlit svoji vysnenou pohadky.

Linuxu pomaham take, ze skolim uzivatele, nasazuji tam kde to ma smysl atd. Nejake upravy kodu atd. to delam na BSD, protoze to neni moje primarni cinnost a kdyz uz to chci delat, tak nekde kde to ma sanci zustat delsi dobu.

Opet je videt bohuzel nepochopeni psaneho textu, protoze nenadavam na Linux jako celek, ale na firmy co si z toho udelali trhaci kalendar a jeste se bohuzel najde dost lidi co to nevidi. Linus a dalsi nadavaji na dost podobne veci, ale kdyz to reknou okni, tak je to svate, kdyz to reknu ja, tak je to blbost, honeni ega a jine veci. Lidska psychologie je proste uzasna

[pavlix]

Ja se bavim uplne normalne.

To je ovšem spíše smutné.

Jen nemam potrebu si nechat omlatit o hlavu nesmysly jako vyvojari z RedHat rikaji, ze nemaji lidi delat BSD

A nemohl bysis své problémy vyříkat s těmi, kterých se týkají? Mně jsou popravdě tvé spory s nimi u řiti a mediátora vám dělat nebudu.

Bavime se tady celou dobu o konkretnich problemech, potvrzuji je i jini Linux uzivatele, je to videt i z ruznych clanku od vyvojaru Linux systemu, Slashdot, The Register a hromady dalsich. Ale nekteri budou porad mlit svoji vysnenou pohadky.

Máš snad namysli mé pohádky, na které se ty sám odkazuješ v diskuzi jako na zdroj? Jako tu wiki stránku o NetworkManageru, kterou jsem vlastnoručně sepisoval? Trochu schizofrenie, ne?

[x]

Uzivatele davaji pomerne dostatecne najevo co si o tom mysli. To co se deje ted o tom nekteri z BSD varovali uz pred hodne lety, tehdy se kazdy smal a dneska se jim zacinaji otevirat oci.

Neprijde ti divne, ze s tolika tisici vyvojari a tolika firmama zapojenyma do vyvoje Linuxu nebo specificky RH/Fedora jsi pouze ty udelal tu Wiki stranku? Ktera znovu rikam, ze je super. Ja vytykal chybejici zakladni funkcnosti v NetworkManageru i po tolika letech vyvoje. Ne ze je to uplne na nic Sve pouziti to ma a to ze ja davam prednost jinemu pristupu na to nema vliv.

[pavlix]

Neprijde ti divne, ze s tolika tisici vyvojari a tolika firmama zapojenyma do vyvoje Linuxu nebo specificky RH/Fedora jsi pouze ty udelal tu Wiki stranku?

Zvykl jsem si :).

Viz mé další pokusy.

Ktera znovu rikam, ze je super. Ja vytykal chybejici zakladni funkcnosti v NetworkManageru i po tolika letech vyvoje. Ne ze je to uplne na nic Sve pouziti to ma a to ze ja davam prednost jinemu pristupu na to nema vliv.

Tady je akorát problém v tom, že odlišný přístup má i spousta lidí z linuxového světa. Tudíž nemá smysl používat NetworkManager jako argument pro nadřazenost *BSD.

Zajímavější jsou všemožné network-related bugy třeba i v kernelu a klíčových nástrojích.

A tady bych si zdalena nebyl jistý zda všechny tyto věci zvládá některé z BSD lépe. Linuxový kernel taky funguje pro statický přístup.

[pavlix]

Kdyz uz tedy neco menili, tak proc to neudelali poradne a nedotahli? Opet je to jen dalsi nedodelek ktery zustal nekde napul cesty.

Nevím jistě, ale tipoval bych to tak, že nechtěli rozbít stávající software.

[jyrki]

Pak to nemeli tlacit do mainstreamu, ale v ramci testingu projekt dokoncit, doladit a uvest v zivot. A ted delaji to same se systemd

[pavlix]

O tom se nehádám, na to nemám dostatek informací :).

[little.owl]

Taky nevim proc rozbijet tradicni Unix postupy, kdyz je staci jen vylepsit devd(8)

Ne, devd neni ekvivalentni nahrada udev.

OpenBSD zvlada tyto veci i se statickym /dev

OpenBSD nezvlada ani spolehlive odpojeni unmountovaneho usb flashdisku, aniz by hrozil pad systemu, natoz neco pokrocilejsiho.

[pc]

OpenBSD nezvlada ani spolehlive odpojeni unmountovaneho usb flashdisku, aniz by hrozil pad systemu, natoz neco pokrocilejsiho.

Nějaký odkaz by nebyl ?

[x]

Ja nerikal, ze je ekvivalentni. Nemusi to opisovat kdejakou blbost. Svuj ucel to plni jednoduse a o to jde.

Ze to OpenBSD nezvlada je potvrzeno nejakym dukazem? Mne to funguje leta s FFS, FAT32 nebo NTFS. A jestli je myslen nedavny problem u JEDNOHO konkretniho uzivatele a specificke verze externiho disku, tak se jednalo o to, ze to byla novejsi revize ses (SCSI enclosure services) coz je pridavna vec k beznemu USB rozhrani a ne tak zcela spravne to reportovalo udaje z citel. System nepadal, ale zatuhl a po restartu byl normalne pouzitelny. Do dvou dnu to bylo opraveno. Navic se jednalo o konkretni revizi jednoho typu externiho disku. Ja k systemu pripojuji mobilni telefony, pouzivam jejich modemy pres USB, pripoji flashky, fotaky, iNeco, Android a zvesela to funguje. Neni to jungle a takoveto veci pouziva denne spousta uzivatelu a takovych veci si hned nekdo vsimne a taky se rychle opravi.

Ale chapu, kdyz dochazi argumenty, tak se hodi kde co.

[little.owl]

Nemusi to opisovat kdejakou blbost.

Kterou funcionalitu u udev povazujete za blbost?

A jestli je myslen nedavny problem u JEDNOHO konkretniho uzivatele a specificke verze externiho disku, tak se jednalo o to, ze to byla novejsi revize ses (SCSI enclosure services) coz je pridavna vec k beznemu USB rozhrani a ne tak zcela spravne to reportovalo udaje z citel. System nepadal, ale zatuhl a po restartu byl normalne pouzitelny.

Ne. Narazim predevsim na to, ze problemy souvisejici s USB na OpenBSD jsou chronicky problem. Posledni OpenBSD, kterou jsem mel nainstalovane na fyzickem PC byla verze 4.7 a tu jsem nahodne sestrelil prostym pripojenim Sansa prehravace k USB portu. Dalsi metoda jak system tehdy znestabilnit bylo kopirovani velkeho souboru - ISO image na externi USB disk a odpojeni kabelu za chodu - system sice nepadl, ale musel se restartovat. Ja vam pevne verim, ze OpenBSD funguje v 99% spravne, ale kvalita OS pozna predevsim v tom jak se chova v krajnich situacich a pripojeni neznamejho nebo novejsiho USB device je to nejmensi co se muze stat, zejmena pokud vetsina vami vyjmenovanych zarizeni pouziva genericky interface typu USB mass storage. Ja neznam detaily implementace USB stacku v OpenBSD, uprimne vzato necitim potrebu s tim systemem jiz ztracet cas, ale zadna robustnost z toho nekouka - i FreeBSD mela postaven stack take na modifikovane libusb a takovehle problemy nemela.

Schvalne jsem otevrel mailing list a zadal ctyri slova - usb storage kernel panic - a prvni mail, ktery jsem dostal je jen tyden stary:

When using current, USB storage devices are not recognized after the machine has been woken from suspend (zzz).

If the storage device is mounted at the time of suspend and is type ffs, then it becomes unavailable and cannot be remounted. When the machine is restarted, the storage device is considered unmounted uncleanly.

If the storage device is mounted at the time of suspend and is type ext2fs, then the kernel panics and drops to ddb. There appears no way to reboot using 'boot dump', 'boot crash', or 'boot reboot' and the power must be cycled to reboot. This happens every time.

Prior to suspending (zzz) the storage devices can be mounted or umounted as normal regardless of whether ffs or ext2fs.

Takze stale stejne. OpenBSD ma nektere veci mozna hezky udelane, specificke pripady pouziti, ale obecne je v pouzitelnosti daleko daleko za Linuxem.

[pavlix]

Ja neznam detaily implementace USB stacku v OpenBSD, uprimne vzato necitim potrebu s tim systemem jiz ztracet cas, ale zadna robustnost z toho nekouka

Verzi bych musel tahat z paty, ale z jiného soudku mě na OpenBSD nefungoval spráně binat (obousměrný nat 1:1), ale vyžadoval pingnutí z jednoho směru pro oživení toho druhého. Takže ani jako síťový router+firewall se mi nakonec OpenBSD neosvědčilo. Byl tam ještě další problém, na který si nemůžu vzpomenout. A flexibilita netfilteru oproti pf mě přesvědčila definitivně.

[x]

Jenomze to je prave ten problem, ze vychazite z 2,5 roku stare zkusenosti. To je presne jako ta povera o tom, ze OpenBSD neni vhodne na desktop a je jen o security.

1) Chovalo se to stejne i na v tehdejsi dobe current? 2) Byl probel reportovan? 3) Byl ten konkretni prehravac podporovan? (sam vite, ze tyhle veci se deji vsude, neni to systemu, na Win/Apple/Lin/Solaris takovych hororovych historek mam taky spoustu), jen na BSD jsem se naucil peclive vybirat HW, predtim jsem to tak neresil 4) Kdyz se divam tady Sansa na Ubuntu, tak je to presne ten priklad ne zrovna povedeneho prehravace, ktery misto aby se choval jako USB pouziva proprietarni MTP, i kdyz to je rozsireni k PTP, tak zadna slava a OS to moc ke slovu nepusti, ale naopak to ma primo v sobe to zarizeni "hruzy" pro Win/Mac a Linux se k tomu dostal za cenu kompromisu. Je mozne, ze na OpenBSD to nebude nikdy, protoze pochybuju, ze toto bude pod nejakou rozumnou licenci, ale kdovi

V krajnich situacich se obvykle zachova tak, ze bud kernel pozna zarizeni, ale neni ovladac a nebo nepozna ani zarizeni a priradi mu nejaky obecny ovladac a pak zalezi, bud staci jen doplnit identifikaci nebo je treba napsat ovladac. Proste jako na Linuxu.

Mailing list jste otevrel, ctyri slova zadal, ale bohuzel vyzkum nedokoncil, protoze by jste vedel, ze to je vec na ktere se dost aktivne ted v current pracuje a nejake problemy se ocekavaji a taky se ocekava, ze je uzivatele nahlasi pokud tu podporu chteji (a opravdu ji chteji, to zadny div samozrejme). Zaroven z toho vyplyva i workaround, nepouzit suspend. Coz muze byt chvilkova neprijemnost, ale neni to nic co by se nedalo prezit. Navic current je nove kazdy den, takze to stejne bude pomerne rychle opraveno a ti kdo to pouzivaji vedi jak si poradit, ostatne v dokumentaci je to taky slusne popisovano.

In fact, as our hope is to continually improve OpenBSD, the goal is that -current should be more reliable, more secure, and of course, have greater features than -stable. Put bluntly, the "best" version of OpenBSD is -current.

Most users should be running either -stable or -release. That being said, many people do run -current on production systems, and it is important that people do so to identify bugs and test new features. However, if you don't know how to properly describe, diagnose and deal with a problem, don't tell yourself (or anyone else) that you are "helping the project" by running -current. "It didn't work!" is not a useful bug report. "The recent changes to the pciide driver broke compatibility with my Slugchip-based IDE interface, dmesg of working and broken systems follow..." might be a useful report.

There are times when "normal" users may wish to live on the cutting edge and run -current. The most common reason is that the user has a device which is not supported by -release (and thus, not -stable), or wishes to use a new feature of -current. In this case, the choice may be either -current or not using the device, and -current may be the lesser evil. However, one should not expect hand-holding from the developers.

Za poslednich 5 let na current se mne jen jednou stalo, ze zmena v kodu zpusobila kernel panic pri velkem vytizeni systemu, ale stacilo jen aktualizovat a chyba byla opravena. Jiste, jini mohou mit vetsi problemy, ale to je dost vyjimecne.

Jde hlavne o to, ze spousta lidi ma zkreslene predstavy o tom jak vlastne co funguje a proc to tak funguje a pomeruji to pohledem bud z davne minulosti nebo neznalosti platformy jako takove. To je sice pochopitelne, ale zbytecne to mate ostatni.

[little.owl]

1) Chovalo se to stejne i na v tehdejsi dobe current? 2) Byl probel reportovan? 3) Byl ten konkretni prehravac podporovan? (sam vite, ze tyhle veci se deji vsude, neni to systemu, na Win/Apple/Lin/Solaris takovych hororovych historek mam taky spoustu), jen na BSD jsem se naucil peclive vybirat HW, predtim jsem to tak neresil 4) Kdyz se divam tady Sansa na Ubuntu, tak je to presne ten priklad ne zrovna povedeneho prehravace, ktery misto aby se choval jako USB pouziva proprietarni MTP, i kdyz to je rozsireni k PTP, tak zadna slava a OS to moc ke slovu nepusti,

Byla to Sansa C200, ktera se chova jako USB mass storage nebo volitelne MTP pokud je na Windows. V podstate stejny problem byl jiz nahlasen dva mesice prede mnou, vcetne obdobneho trace, problem byl umass driveru. Mel jsem z toho pocit nevyzralosti implemantace USB stacku, protoze bez ohledu na to co na USB pripojim to nesmi sestrelit kernel. Jaka je situace ted nevim, ale skutecne tech reportovanych problemu kolem USB je stale plno, obecne u vsech BSD, ale mozna jsem jen rozmazlen pomerne dobrou implementaci v Linuxu.

[x]

Je to mozne, ale z tech duvodu bylo USB prepsano (a to i na jinych BSD). Je zcela samozrejme, ze je nutno drzet krok. Drtiva vetsina "problemu" je ve stylu pridani spravneho ID do spravneho konfiguraku aby to system detekoval. S USB problemy se setkavam i na Windows (zrovna dneska rano), pripadne Linux dlouhou dobu nektere kamery od Logitech atp. Hlavne pokud mam moznost, tak reportuji problem at se zlepsi podpora a je jedno u ktereho OS. Pravda, u Win to moc smysl nema

[little.owl]

Je to mozne, ale z tech duvodu bylo USB prepsano (a to i na jinych BSD).

Zadni div, ze je to pytel plny problemu, kdyz to stale prepisujete, navic s ohledem na malou testovaci bazi.

Drtiva vetsina "problemu" je ve stylu pridani spravneho ID do spravneho konfiguraku aby to system detekoval.

Tady jsme se bavili o generickych driverech. U zarizeni na USB, ktere se deklaruji jako mass storage zadne specialni ID nepotrebujete. A kdyz uz to vyrobci podelaji, od toho jsou udev rules - ta odporna komplexni obluda, ze.

pripadne Linux dlouhou dobu nektere kamery od Logitech atp.

Kazda kamera kompatibilni s Win Vista/7/8 musi byt kompatibilni s generickym UVC driverem, ktery je ted na Linuxu lepsi nez ve Windows, Logitech do nej prispival a jako jedna z mala firem sve kamery s Linuxem skutecne testuje.

[x]

To je legracni, tak proc Linux prepisuje init?

ID jsem mel na mysli trochu jine Pridani podpory USB zarizeni , ne neco s cim se potyka admin nebo uzivatel

Nemluvil jsem o UVC, ktere je standard, ale hromady jinych kamer co nejsou UVC a jeli pod Linuxem, pak nekdo zacal "prepisovat" a najednou to nejelo a nebylo moc zabavne kupovat novou kameru jen proto, ze se rozhodl nekdo "vylepsit" system. Sam uz kupuji jen UVC, protoze to funguje napr. i na Solarisu.

[little.owl]

To je legracni, tak proc Linux prepisuje init?

Je rozdil prepisovat neco porad dokola nebot predchozi verze byla zvrtana a nahradit neco necim, nebot to nove prinasi novou funkcionalitu, coz je bez debaty pripad systemd.