Arch Linux přejde na Systemd (diskuse)

[Jardík]

Bože, další brainfuck

[l4m4]

Že ses konečně přiznal...

[xm]

No konečně

[mess]

Přijde mi to jako logický krok. Stejně to k tomu směřuje.

[alium]

souhlasím, navíc se vývojáři nemusí dále starat o initscripts

[alium]

přešel jsem kompletně před 2 dny. Podle wiki, přechod naprosto bez problémů. Nevidím v tom jako uživatel moc velký rozdíl.

[KejPi]

Ja jsem presel kdyz udev vclenili do systemd a udev ziskalo libsystemd jako zavislost. Prechod podle wiki byl naprosto trivialni, vubec to nebolelo a z uzivatelskeho hlediska nevidim zadny rozdil mezi systemd and sysv.

[little.owl]

Blahopreji Arch ke spravnemu rozhodnuti! Ja si stejne vzdy myslel, ze uzivatele Arch jsou jen zdivoceli uzivatele Fedory a adopce jejich veci to spise potvrzuje.

[l4m4]

Představa, že by uživatelé Fedory mohli zdivočet, mne poněkud zneklidňuje...

[Fluttershy, yay!]

[relevant]

[little.owl]

Hezky clanek. Pokud by Arch chtel delat veci jinak nez Red Hat, prinesete to praci navic. Jsou jeho uzivatele ochotni to konzistentne a dlouhodobe delat? Pokud ne - a vyvojari Archu o tom take nejsou presvedceni - je prebirani veci z Fedory jedina rozumna cesta.

[kolcon]

... pak ovsem asi neni duvod, aby arch existoval a muzou se pouze pridat jako dalsi repo fedory...

jsem rad, ze se aspon Gentoo a Debian drzi dal od veci, propagovanych Lennartem Poetteringem (a Miguelem de Icazou)

[Fluttershy, yay!]

Aha, už je tu ten „argument“: „Nemám rád Lennarta.“

[blami]

+1, pritom Lennart udelal pro linuxovy userspace spousta viditelne prace a presto, ze ho nemam rad jako cloveka, musim rict ze je to skvely inzenyr.

[kolcon]

ano? co napriklad? tragedii jmenem pulseaudio?

[little.owl]

Tragedii? Ani nahodou, ukazte mi jedinou ekvivalentne schopnou aplikaci.

[tomasgn]

to by mne zajimalo, na co to potrebujete. ja pulseadio jako zbytecny bazmek ihned vykopavam ze systemu, a nijak mne nechybi, vsechno hraje.

[Václav "Darm" Novák]

Přepínám aplikaci mezi dvěma zvukovkama, snadné připojení USB mikrofonu ve webkameře, jednoduchá správa hlasitostí každé aplikace zvlášť (ano, umí to i OSS, ale to zase neumí pořádně USB zvukovky a suspend).

[alium]

pulseaudio není žádná tragedie, alespoň ne poslední verze... podle mně jsi pulseaudio zkoušel někdy dávno, něco nefungovalo a od té doby na něj nadáváš (můj odhad...).

Pulseaudio je například jako jediné shopno bez problémů připojit a přepnout zvuk za běhu  do mých BT sluchátek.

[stativ]

Pulseaudio je například jako jediné shopno bez problémů připojit a přepnout zvuk za běhu  do mých BT sluchátek.

To je asi tak všechno, co PA dovede dobře.

Zrovna na tohle téma byla zajímavá diskuse na Arch-general. Výsledek – většina obhájců PA uznali, že PA má problémy, kvůli kterým je pro některé lidi naprosto nepoužitelné. Nejpalčivějším tématem bylo nastavení hlasitosti, které PA dělá pomocí magie, aniž by vědělo, jak to v reálu ovlivní zvuk, protože to šteluje s digitálním zesílením i s analogovým zesílením. Co je mi známo, tak nedovede pracovat s kartami založenými na ice1712,kde prý rozbíjí velkou část vstupů a výstupů (místo toho je nějak sloučí), u jiných lepších zvukovek se tenhle problém prý taky vyskytuje. Při realtime zpracování zvuku jsou taky dost problém naprosto nedeterministické latence.

Takže pro desktop je to OK, ale pro zvukařinu je to zřejmě ta nejhorší věc, co mohla linux potkat.

[alium]

Pro zvukařinu asi ano, ale tambych předpokládal nějaké více sofistikované/specializované nástroje.

Líbí se mi na Archu, že hodně věcí vč. PA je optional. Takže jej nemusí používat ti co nechtějí/u kterých to nefunguje správně.

[Jardík]

Pulseaudio je šmejďárna dělající z mé Audigy 2 ZS softwarový šmejd s latencí jakhovno, kvůli SW mixování to zpomaluje třeba hry o několik FPS, krade mi možnost přizpůsobit si vše v alsamixeru, krade mi spoustu šoupátek.

Na notebooku s int. zvukovkou mi pulseaudio není schopné přehrávat přes interní repro, pokud mám zastrčeny sluchátka, normálně s alsou si můžu vybrat, jestli budu mít int. repro zaplé při zastrčených sluchátkách, nebo ne. Pulseaudio mi nějak routuje zvuk do obou výstupů na sluchátka (můj NB má 2) najednou, nemůžu mít v každých něco jiného, s Alsou ano.

[dustin]

S alsou to jde, protože si to každý driver řeší po svém. PA je vrstva společná pro všechny zvukovky a potřebuje standardy, které si v alse (vrstvě pod PA) teprve sedají (např. jednotné názvy ovládacích prvků) či teprve vznikají (např. alsa-jack API http://git.alsa-project.org/?p=alsa-kmirror.git;a=blob;f=include/jack.h;h=58916573db582eab1d19a6d751ebe516c194b834;hb=HEAD ). Až si to v alse sedne a PA to začne používat (PA je hlavním motivátorem těchto nových věcí v alse na desktopu), věřím, že to bude fungovat OK.

[Jardík]

Jenže do té doby je pro mě pulseaudio nepoužitelné stejně jako bylo pro mě nepoužitelné dodnes (je to již pár let). Stejně tak je pak nepoužitelné vše, co pulseaudio vyžaduje. Alsa mi spolehlivě funguje na desktopu i notebooku, s vlastnostmi, které chci/potřebuji, pulseaudio ne a to je pro mě důvod, proč pulseaudio nesmí na můj systém.

[dustin]

To je v pořádku, tak jej nepoužívej. Jsi pokročilý uživatel, umíš si poradit.

[mimi.vx]

Audigy jsou karty kterym se vyhnout obloukem jak v Linuxu tak Windows ... --

[Jardík]

Důvod? Já s ní nemám problém ani v Linuxu, ani ve Windows.

[Jiří J.]

No, na Windows funguje o něco lépe ...

Díky hardwarovému resamplování všeho na 48K jsem ji také po čase odepsal. Ona celá Audigy série byla spíš mířena na hráče a přidané efekty (2 ZS má dedikovaný efektový procesor, to samé X-Fi, ...) spíše než na kvalitu analogového signálu. Musím říci, že i s levnou E-MU 0204 kvalita poskočila o pěkný kus a podpora v Linuxu je na přijatelné úrovni.

Ontopic: pulseaudio je samozřejmě "konzum", podobně jako "MP3 přehrávače" za pár desítek korun. Tam se hraje prakticky jen na funguje/nefunguje a jak cool to vypadá. Dokud půjde na kartách přehrávat přes hw:X,Y přímo, pak ať si pulseaudio nasazuje, kdo chce.

[dustin]

Jistěže přehrávání přes hw:X,Y půjde, přes to samé přehrává i pulseaudio :)

Ano, PA míří na obyčejné uživatele. Znalejší nemá problém jej obejít, za cenu aplikace svých těžce získaných znalostí :)

[mimi.vx]

Kvalita ... A problemy po prechodu na Wista a vys ...

[Jiří J.]

Kvalita ano. Problémy na Windows Vista / 7 ne, tam mi karta šlapala bez problému. Existuje i prográmek zvaný Audio Console for Creative Sound Blaster Audigy, přes který se dají měnit různé vlastnosti karty a který (narozdíl o zbytku Creative softu pro Audigy) funguje i na Windows 7.

Problémy leda s přídavným softwarem, který byl na CD u karty, ale to nijak nesouvisí s drivery samotnými.

[Jardík]

Někde se válelo neoficiální instalační CD pro x64 vista co někdo spatlal s funkčním přídavným SW vypreparovaným tuším z Audigy 4 (nebo jestli to nebylo x-fi) včetně patchnutýho programu od creative, co zprovoznil EAX na Vistě (bez kterého např. nešel zvuk v Metal Gear Solid Substance, protože MS EAX vyhodil)

[2X4B-523P]

používám ji místo integrované zvukovky, má kvalitnější zvuk, mikrofonní předzesilovač atd. mám Audigi 2 a nedám na ni dopustit, je i lepší než AWE64, kterou jsem měl předtím... (na AWE32 a Gravise už ale nemá, ale stejně už nikdo lepší zvukovky nevyrobí, tak je to jedno )

[little.owl]

Ukazte mi funkcni ekvivalent s mensimi latencemi.

protože to šteluje s digitálním zesílením i s analogovým zesílením

To je normalne pouzivane reseni.

[stativ]

Ukazte mi funkcni ekvivalent s mensimi latencemi.

JACK.

To je normalne pouzivane reseni.

Normálně si to šteluje člověk, který dovede rozhodnout, co se má jak nastavit a ne nějaká magie, která jen hádá.

[Lol Phirae]

Normálně si to šteluje člověk, který dovede rozhodnout, co se má jak nastavit a ne nějaká magie, která jen hádá.

Kdepak, uživatel by byl zmaten přílišným množstvím nastavení.

[stativ]

Jo tak proto Gnome 3 vyžaduje PA

[little.owl]

JACK je vhodnejsi pro profesionalni zpracovani zvuku ve staticke konfiguraci, ale normalniho uzivatele to neni funkcni ekvivalent.

Normálně si to šteluje člověk,

Normalne se ve vetsine aplikaci pouziva adaptivni equalizace.

[trekker.dk]

Normalne se ve vetsine aplikaci pouziva adaptivni equalizace.

Co je tohle za nesmysl?

[little.owl]

Mysleno tak. ze mixery OS pouzivaji adaptivni softwarovy limiting/compression k zabraneni clippingu. Pro uzivatele je totiz asi prijatelnejsi relativni pokles hlasitosti pri mixovani vice signalu, nez artefakty zpusobene orezanim.

[Lol Phirae]

"Jednotlivý člen sociální skupiny často přijímá informace cestou vizuálních symbolických kanálů." Feynman posléze pochopil, že věta znamená "lidé čtou".

[hmmm]

Jenze na linuxu profesionalni zpracovani zvuku neexistuje. Zadny DAW co by nebyl amtersky komunitni bastl bohuzel neexistuje... Ardour nebo treba Traverso jsou k seriozni praci asi jako XPaint k Photoshopu. Myslim ze za to muze prave zalostny stav linuxovych "soundsystemu", latence kernelu a samozrejme totalni nezajem skutecnych firem na portaci svyvh DAW

[kyytaM]

Naozaj?

[hmmm]

A v kterem studio do toho toci? Hmmmm, v zadnem... A v linuxu to rozhodne neni bezproblemove, tzn nepouzitelne. Zkousel sem.

[dustin]

http://old.nabble.com/Linux-Studios-roundup-ts34196139.html

[hmmm]

Tak to je spis usmevne.... Home studia neberu... Sorry. Linux na zvuk fakt neni mam ho uz od roku 2004 a porad nic. Linux mam rad ale na DAW je fakt uplne na hovno.

[dustin]

Mně se omlouvat nemusíš :) Je mi úplně fuk, co používají profi studia. Pro mě je podstatné, že když budu potřebovat něco nahrát, vím, že to celkem bez problémů půjde. Určitě mi to zabere dost času, ale ten čas strávím učením něčeho nového, to se nikdy neztratí. Bude to pro mě zábava, takže nebudu řešit "čas jsou peníze".

Mimochodem, který OS má nižší latenci při stejné spolehlivosti jejího udržení, než linux (kernel) nastavený dle "best practices" pro realtime audio?

[little.owl]

OS má nižší latenci při stejné spolehlivosti jejího udržení

SYS BIOS?

[kyytaM]

Co myslis, na com bezi toto? Zisti si, v akych studiach to je a ake veci sa na to robia a robili.

[hmmm]

Tak to bezi linuxu, ale ten tam maximalne hejbe savlema v pultu. To je jako tvrdit, ze kdyz maj v atomovy elektrarne linuxovej routr, ze jim to cely bezi na linuxu...

[little.owl]

Linux mam rad ale na DAW je fakt uplne na hovno.

A konkretni technicke duvody, proc by Linux kernel mel byt tak spatny nebo horsi nez treba Mac ci Win?

[hmmm]

Zadne technicke duvody neznam, ale fakt je ze lin proste nahravat hudbu neumi... Sorry tahle diskuze nema cenu. Asi jste mockrat nikde nic nenhravali...

[Martin Mareš]

Pokud technické důvody neznáte a ani se neumíte podepsat, pročpak bychom vám měli vaše velkotlamá tvrzení věřit? Pakliže se nevytasíte s argumenty a pouze vedete prázdné řeči, pak věru další diskuse nemá cenu.

[kavol]

ehm, jakkoli souhlasím s jádrem příspěvku, musím se ohradit vůči tomu, že by hodnota názoru nějak závisela na tom, jak se autor podepisuje ... kdyby napsal "Josef Novák", učinilo by to jeho příspěvek hodnotnějším? je "Martin Mareš" lepší člověk než "mj"?

[Michal Kubeček]

No, on je přeci jen trochu rozdíl mezi nickem, který člověk používá trvale a v některých případech už mnoho let, a tím, když svůj příspěvek "podepíše" tím, co ho zrovna napadne.

[kavol]

mno, v tomto konkrétním případě jsem měl za to, že podpis "hmmm" se tu také již nějaký pátek vyskytuje

nejsa správcem nemohu tipovat dle užívaných IP adres, zda jde vždy o stejnou osobu a zda tato nepoužívá ještě i jiné přezdívky, nicméně nemyslím, že by šlo o případ "co ho zrovna napadne"

leč to není přesně to, co jsem měl na mysli, vizte níže

[Martin Mareš]

Pokud někdo svůj názor nezdůvodní, jediné, co by ho ještě mohlo učinit věrohodným, je reputace autora. A tu někdo, kdo používá náhodné nicky, sotva nemá.

[kavol]

já bych řekl, že to je dost zásadní omyl, to by mělo fungovat jen jednosměrně - pokud je reputace autora mizerná, měl by k tomu člověk a priori přistupovat s pochybnostmi, ovšem sebelepší reputace by neměla znamenat, že vyřčené bude člověk brát jako písmo svaté ... předpokládám, že situací, kdy nějaká "autorita" tvrdila s vážnou tváří bludy, jsi již potkal dost

pochopitelně, v praxi je jednodušší názory "autority" přebírat nežli vše pečlivě ověřovat, ale pokud už se dostaneme k pochybnostem o validitě názoru, pak by již otázka, kdo ten názor vyřkl, měla jít stranou

ohledně náhodných nicků viz výše; ještě bych doplnil, že důvody k anonymitě (pokud "hmmm" nezkonstatujeme za normální přezdívku) mohou být mnohem prozaičtejší, nežli neochota hlásit se k nějakému názoru

[Martin Mareš]

Já to beru spíš tak, že pokud tvrzení, které vypadá velmi podezřele, vyřkne někdo s dobrou reputací, má smysl nad tím hlouběji přemýšlet a pokoušet se ověřit, jestli to náhodou není pravda. Ale pokud ho vyřkne někdo jiný, nakládám s takovým tvrzením do /dev/null.

[little.owl]

Vas pristup je prirozeny, autorita, renome ci reputace je neco co se pracne ziskava roky, snadno ztraci a clovek se s tim nerodi.

[kavol]

Já to beru spíš tak, že pokud tvrzení, které vypadá velmi podezřele, ...

no, a jak takové tvrzení typicky poznáš?

[Michal Kubeček]

To je asi tak smysluplná otázka jako "Jak poznáte, že je vám horko?"

[kavol]

mno, podle mého si ve smysluplnosti nezadá s tím, nač tato otázka reaguje ...

ale jistě takto ji shodit je jedodušší, nežli pokusit se jí zodpovědět, a tedy třeba narazit na problém

že je mi horko poznám tak, že neuroreceptory začnou přijímat signály o zvýšené teplotě a síť neuronů dále tuto signalizaci transformuje z pocitu na myšlenku, kterou jsem schopen si uvědomit; sekundárně mohu pozorovat reakci na tento stav v podobě zčervenání - vyšší prokrvení kůže za účelem většího vyzařování tepla do okolí - a pocení

jak obecně o nějakém tvrzení poznám, že mi má být podezřelé?

[kralyk z abclinuxu]

omg, co je tohle za člověka?

[Michal Kubeček]

jak obecně o nějakém tvrzení poznám, že mi má být podezřelé?

To už je ale úplně jiná otázka. Původní otázka zněla "Jak poznám, že je mi tvrzení podezřelé", ne "jak poznám, že mi má být podezřelé". To, jestli je vám tvrzení podezřelé, prostě víte, to je subjektivní pocit, stejně jako to, jestli je vám horko. A stejně jako vedle sebe mohou sedět tři lidé, z nichž je jednomu horko, druhému chladno a třetímu tak akorát, u téhož tvrzení se celkem snadno může stát, že jednomu bude podezřelé, druhého o něm ani nenapadne pochybovat a třetí bude stoprocentně přesvědčen, že není pravdivé. A to bez ohledu na to, jestli je to tvrzení objektivně pravdivé nebo ne.

[kavol]

jak obecně o nějakém tvrzení poznám, že mi má být podezřelé?

To už je ale úplně jiná otázka. Původní otázka zněla "Jak poznám, že je mi tvrzení podezřelé", ne "jak poznám, že mi má být podezřelé".

v pořádku, však taky ta druhá otázka byla položena v jiném kontextu - ostatně původní otázka nezněla "Jak poznám, že je mi tvrzení podezřelé" nýbrž "a jak takové tvrzení typicky poznáš?"

To, jestli je vám tvrzení podezřelé, prostě víte, to je subjektivní pocit, stejně jako to, jestli je vám horko.

i ten subjektivní pocit se dá objektivně popsat - právě ono horko je toho krásným příkladem, pokud se někdo potí, pozná se, že mu je horko (nemá-li nemoc, při které se potí jen tak)

A stejně jako vedle sebe mohou sedět tři lidé, z nichž je jednomu horko, druhému chladno a třetímu tak akorát, u téhož tvrzení se celkem snadno může stát, že jednomu bude podezřelé, druhého o něm ani nenapadne pochybovat a třetí bude stoprocentně přesvědčen, že není pravdivé.

ano, jistě, může ... a mě zajímá, jaké okolnosti přiměly toho prvého považovat to za podezřelé

A to bez ohledu na to, jestli je to tvrzení objektivně pravdivé nebo ne.

no, pokud tam žádný takový vztah není, pak mi jaksi uniká smysl toho vzývání autorit ...

[Michal Kubeček]

no, pokud tam žádný takový vztah není, pak mi jaksi uniká smysl toho vzývání autorit ...

Ne že by nebyl vůbec žádný, je tam nějaká korelace, obvykle tím vyšší, čím víc se dotyčný v daném oboru sám vyzná.

Formulaci "bez ohledu na to, jestli je to tvrzení objektivně pravdivé nebo ne" jsem myslel ve významu "…a to se může stát jak v případě, kdy je dané tvrzení objektivně pravdivé, tak v případě, že je objektivně nepravdivé."

[dustin]

Jack a pulseaudio mají úplně jiné cíle. Ano, obojí umí sloučit více streamů (jack pouze stejné vzorkovací frekvence), ale to je asi tak všechno. Z pohledu latence je primárním cílem PA dynamicky přizpůsobovat latenci dle aktuálních požadavků kvůli spotřebě baterií notebooků - viz klasika http://webcache.googleusercontent.com/search?q=cache:gfAMRSLenXoJ:0pointer.de/blog/projects/pulse-glitch-free.html+http://0pointer.de/blog/projects/pulse-glitch-free.html&cd=1&hl=cs&ct=clnk&client=ubuntu . Primárním cílem jacku je latenci maximálně minimalizovat :)

[little.owl]

JACK2 lze pouzit s PA, chystam se to zkusit s Behringer UCA202.

[dustin]

Nevím, zda to teď není jinak, ale původně to myslím mělo fungovat tak, že jack před otevřením zvukovky (tedy spuštěním streamu) dočasně vypne (pasuspender) PA, tím si uvolní zvukovku pro sebe, a pak jej zase nahodí. Pochybuji, že by jack šel přímo přes PA.

[little.owl]

No, ja to jeste nezkousel, ale chapu to tak, ze pokud JACK2 chce zvukovku, tak si o ni pres D-Bus rekne a PA ji uvolni, s tim ze PA se muze k JACK2 pripojit.

[dustin]

Jo to zni rozumne.

[kavol]

... je primárním cílem PA dynamicky přizpůsobovat latenci dle aktuálních požadavků kvůli spotřebě baterií notebooků ...

tak to je hodně smutný, že ani po tolika letech vývoje ten svůj primární cíl nejsou schopni dosáhnout a s PA se procesor při přehrávání muziky zapotí podstatně víc než bez PA ...

(tedy nevím, jak by to na tom bylo s jackem, ale WTF nač používat nějakou takovou pikatchovinu pokud si přehrávač rozumí s alsou samotnou)

[little.owl]

Spise by bylo smutne pokud primarnim cilem PA je setrit baterku, nikoliv prehrat rozumne zvuk.

[dustin]

Na "pouhe" prehrani zvuku samozrejme staci alsa. Cilem jineho zpusobu komunikace PA se zvukovkou, nez je normalni rizeni prerusenim, je pri tom prehravani hudby s latenci klidne 1 sekunda (tedy mezitim cpu spi) napriklad prijmout voip hovor s latenci treba 10ms.

[little.owl]

Ja bych ocekaval dva profily, jeden low power, klidne i s vetsi latency a druhy, kde se latency bude minimalizovat i za cenu vyssi spotreby. Uzivatel si rozhodne.

[dustin]

Kdyz uz ta muzika bude hrat, je na rozhodnuti pozde. Ve standardnim modelu alsy nelze zmenit latenci bez preruseni streamu a naalokovani novych bufferu.

Udajne ten glitchfree rezim mely v te dobe uz win i mac.

[little.owl]

Kdyz uz ta muzika bude hrat, je na rozhodnuti pozde.

Ja mel na mysli check-box v nastaveni, jehoz zmena muze vest k restaru zvukoveho subsystemu.

[stativ]

Udajne ten glitchfree rezim mely v te dobe uz win.

To je ten systém, kde je občas slyšet scrollování ve sluchátkách?

[dustin]

To je slyšet i na jiných OS, jde o bordel vznikající při interruptech nebo při CPU špičkách na napájení. Na jednom linuxovém stroji jsem slyšel nejen pohyb myši, ale i vypisování písmen do terminálu (i jako vzdálená odpověď, ne z mé klávesnice). Třeba při pomalé lince na server to krásně klapalo :)

[little.owl]

To jsou interference pramenici prevazne z designu HW.

[Stanislav Brabec]

Hlavní problém PA je to, že se snaží využít vše, co ALSA nabízí.

Zatímco všechny ostatní programy vesele tlačí data do bufferu, PA si udělá mmap(), a ten naplňuje po částech. Vyžádá si přerušení, když je vybraná část bufferu přehraná. Výsledkem by měla být nízká latence, a nižší počet přepnutí úloh.

A tady nastává problém. Ačkoliv je ALSA s námi už 10 let, nikdo tyto vlastnosti nikdy pořádně netestoval. A najednou se objevily v ALSA spousty letitých chyb, které bylo třeba opravit.

Uživatel to ale viděl jednoduše: PA je rozbité.

Na kouzlení s kanály neposkytuje ALSA dostatek informací, takže je potřeba, aby měl PA vlastní databázi. ALSA poskytuje jen textový název regulátoru nebo přepínače. Neposkytuje však informace, kudy se zvuk v konkrétní kartě routuje, které regulátory na něj mají vliv, a za jakých okolností, ke kterému vstupu je přiřazen konkrétní regulátor, které dráty končí ve vzduchu, zdali je bluetooth čip připojen přímo do zvukového subsystému, jak je připojeno FM rádio, zdali má televizní čip nebo CD mechanika připojen vlastní zvukový kanál. Některé karty nemají centrální regulátor zvuku, jiné mají naopak dva (analogový a digitální).

Zkuste v tomto zmatku napsat něco, co bude fungovat všude, bez laborování uživatele s desítkami šoupátek.

Když jsem svého času rozchozoval ALSA konfiguraci WM8750, trvalo mi několik hodin, než jsem dokázal 65 ovládacích prvků zvukového čipu nastavit na výstup na sluchátka, výstup na reproduktor, na headset, a na mikrofon. Bez datasheetu zvukového čipu a schématu zapojení konkrétního zařízení bych to asi nedal.

[dustin]

Přesně tak. PA vyžaduje funkce alsy, které nikdy pořádně nefungovaly.

Realita je taková, že se alsa pořád víc překlápí v kvalitní backend s užitečnými API definovanými reálnými potřebami "klientů" a stahuje se z user-space vychytávek typu dmix, spoustu pluginů do alsa-libu atd. To přenechává pulseaudiu, které pro změnu míří i do embedded prostředí a řeší uživatelské věci. Tak mi to přijde správně. Na obou stranách je plno chyb a nedodělávek a obojí jde rychle dopředu.

[little.owl]

+1 Vystihl jste to dobre.

[kavol]

A tady nastává problém. Ačkoliv je ALSA s námi už 10 let, nikdo tyto vlastnosti nikdy pořádně netestoval. A najednou se objevily v ALSA spousty letitých chyb, které bylo třeba opravit.

Uživatel to ale viděl jednoduše: PA je rozbité.

kde já jsem jenom tohle viděl ...

jo už vím, KDE4 jak padalo na hubu, tak za to mohly všechny možné grafické drivery - výborná příležitost kopnout si do té zlé hnusácké proprietární nVidie; že to padalo i na super otevřeném Intelu, hm, smůla, a že na týchž driverech bez problémů běhaly náročné 3D hry, to o ničem nevypovídá, protože ty přece tu grafiku vůbec nepoužívají, to jenom KDE4 odhalilo ty letité chyby v driverech

takže když je nad alsou funkční třeba JACK, tak to taky o ničem nevypovídá, to jenom to skvělé a bezchybné PA využívá featury, které nikdo jiný ne, a odhaluje tudíž letité chyby v alse, protože PA je prostě bezchybné (to už jsem říkal, ale je potřeba to ještě jednou zdůraznit, že PA prostě nemá chybu)

jděte už s tím k šípku ... coby uživateli mi bohatě stačila nedávná zkušenost zprovoznění ekvalizéru nad čistou alsou (Gentoo) a nad PA (Fedora) - s alsou mi stačilo přidat preamp plugin, s PA je to neřešitelný (resp. zatím nevyřešený) problém

[dustin]

Jack ani zdaleka nepoužívá API alsy v takové šíři, jako PA. Z pohledu alsy je to úplně normální alsí aplikace, možná ani nepřistupuje k zařízení controlX - ovládací prvky alsy (hlasitost, přepínače...). PA mapuje nepřebernou houšť různých ovládacích prvků různých zvukovek na jednotné rozhraní. Je to první projekt, který se o něco takového nad alsou pokusil. Samozřejmě, že vychytání všech variant (zahrnuje i změny v alse) je na dlouho. Všimněte si, že např. ASIO ovládací prvky neřeší vůbec a součástí ovladače od výrobce je GUI ovládacího panelu - každý pes jiná ves, jednotnost i skriptovatelnost žádná. Jediné, co ASIO umí, je zavolat zobrazení ovládacího panelu - ASIOControlPanel. Je to prostě boj.

Nikdo neříká, že je PA bezchybné. Je plné bugů, stejně jako alsa, jejíž chyby PA vždy rychle odhalí.

Pokud jsi pokročilý uživatel, PA odinstaluj a užívej si volnosti a konfigurovatelnost alsy. Ale pro BFU nemám s PA problém, teď už ne (v posledním roce, dvou).

[kavol]

Náš administrátor shledal tento komentář závadným.

Zbytečně vulgární

Zobrazit komentář

[Lol Phirae]

jdi do píče s takovou "radou" - fakt nemám čas ani chuť věnovat týdny úsilí řešení, jak se PA zbavit, když se tvůrci distra rozhodli, že to bude default (ditto obdobné rady tady porůznu okolo, že volba systemd nikomu nebrání používat jiný init)

A ta jadrná horalská mluva, jak stříbrně zvoní v ústech rázovitého lidu.

Teď ti "poradí", ať změníš distribuci. A až nebude možné ani to, tak ti "poradí", ať si vytvoříš distribuci vlastní.

Shrnutí transakce
=======================================================================================================================================================================
Remove  2 Packages (+325 Dependent packages)

Nainstalovaná velikost: 2.2 G
V pořádku [a/N]:

Víš, jak by se ti pěkně pročistil a zrychlil systém?

[kralyk z abclinuxu]

Teď ti "poradí", ať změníš distribuci. A až nebude možné ani to, tak ti "poradí", ať si vytvoříš distribuci vlastní.

Možná se ti to zdá jako blbá rada, ale taková prostě je realita, resp. může být. Můžeš na to nadávat na fóru a v hospodě, můžeš proklínat Lennarta (nebo kteréhokoli jiného třídního nepřítele) třeba do horoucích pekel, ale pokud majorita učiní nějaké rozhodnutí ve světě FOSS, nic jiného ti nezbyde. Můžeš si klidně doma vytvořit Lennartovu sošku a bodat do ní jehly, pokud ti to uleví, ale na situaci tím nic nezměníš.

Mně osobně by se taky určitě nelíbilo, kdyby v mým distru zavedli povinné PA (mnohem radši bych viděl dodělání OSSv4), ale kdyby se to (nedejbože) stalo, tak nebudu fňukat někde na fóru (takhle už jsem úspěšně poslal Akonadi tam, kde slunce nesvítí). A to ty a někteří další ještě vůbec případi - fňukáte preventivně ještě než daná "katastrofa" vůbec nastane

[Michal Kubeček]

ale pokud majorita učiní nějaké rozhodnutí ve světě FOSS, nic jiného ti nezbyde

Kdybych věděl, že to rozhodnutí učinila majorita, tak bych ho akceptoval mnohem snáze. Ve skutečnosti je bohužel spíše dílem poměrně malé skupiny lidí a majoritě je pouze dáno na vědomí.

[l4m4]

Kdybych věděl, že to rozhodnutí učinila majorita, ...

Majoritu žádné činění rozhodnutí u deseti tisíc jednotlivých projektů nezajímá. Hospodští, pardon fóroví, stěžovači nejsou majorita.

Ne, že by se mi vždy líbilo, kam různé projekty míří, ale rozhodnutí v OSS činí ti, kdo přispívají, a v jednotlivých projektech (příčetně vyvíjených) funguje meritokracie. A to je dobře.

Demokracie pak probíhá hlasováním nohama: je-li něco totální hovadina, přestane se to postupně používat. Něčí totální hovadina je ovšem pro jiného úžasný a nepodstradatelný program...

[kavol]

Kdybych věděl, že to rozhodnutí učinila majorita, ...

Ne, že by se mi vždy líbilo, kam různé projekty míří, ale rozhodnutí v OSS činí ti, kdo přispívají, a v jednotlivých projektech (příčetně vyvíjených) funguje meritokracie. A to je dobře.

kdyby ta rozhodnutí aspoň činili všichni, kdo přispívají, resp. kterých se při tom přispívání daná věc týká ...

Demokracie pak probíhá hlasováním nohama: je-li něco totální hovadina, přestane se to postupně používat.

no, to je taky dobrej názor ... takže zahodím distro a zmigruju někam jinam (kam, na wokna nebo na distro, co danou věc přijme až za půl roku?), který mi jinak vyhovuje, jen kvůli jedný pikatchovině?

to je něco takovýho, jako mi tuhle borec z ÚOOÚ na dotazy ohledně dat z RFID zámku řekl nepřímo, že jsme neměli kupovat byt, když s tím máme problém, a že když už jsme ho koupili, tak jsem "dohodu" o klíčích určitě nepodepsal pod nátlakem, ač byla podmínkou předání těch klíčů (na otázku, jakou jsem podle něj měl alternativu, zda například přistavení vysokozdvižné plošiny a vstup oknem považuje za adekvátní, se raděj vyhnul odpovědi) ... hm, a že parametry typu bezbariérovej přístup (pro kočárek) apod. byly důležitější, než zda si nějaká baba domovnice může masturbovat nad statistikou, v kolik chodíme domů, aniž by měla oko červený od zírání do kukátka, no tak to jsem úplnej magor, že to takhle vážím, to jsem se na ten byt kvůli tomu jednomu problému měl vysrat a radšit si zkrátit úvazek a bejt místo v práci doma, abych mohl ženský s tím kočárkem pomáhat do schodů, a smířit se s hlučnější (a zasmrděnější) lokalitou, anebo menším bytem, anebo podstatně delším dojížděním do práce, anebo milionem jinejch věcí, a ještě za to vypláznout víc peněz, že ...

p.s. není tu nějakej hacker z Brna, co by uměl zduplikovat 64bit čip v pásmu 125 kHz, konkrétně z-ware?

[l4m4]

takže zahodím distro a zmigruju někam jinam ... který mi jinak vyhovuje, jen kvůli jedný pikatchovině?

Granularita je obecně jeden projekt (program, knihovna, ...), někdy menší, někdy samozřejmě větší kvůli vzájemné provázanosti hovadin. Je-li totální hovadina distro, tak musíš vyměnit to.

Ale jinak jsem rád, že na rozdíl od nás chudáků žiješ v ideálním světě, kde nikdy nejsou zapotřebí kompromisy, a přeji ti to.

[kavol]

čteš na co reaguješ? víš o čem je toto diskusní vlákno?

[l4m4]

Vím o čem je toto diskusní vlákno. Tudíž jsem si vcelku jist, že není o tvých problémech s bytem.

[kavol]

nadhodil jsem otázku, o čem je, nikoli o čem není - vidím, že buď máš zcela zásadní problémy s jazykem, nebo troluješ, nebo seš prostě jen blbej jak tágo na pingpong ...

[little.owl]

Tak rozhodnuti ucini spise vyvojari a nebo jejich zamestnavatel.

[Michal Kubeček]

Jinak řečeno: měl jsem pravdu, když jsem se ohradil proti tvrzení "majorita rozhodla".

[kralyk z abclinuxu]

Já jsem tou majoritou měl na mysli přebírání dané věci distribucemi.

[stativ]

Asi jeden z nejčastějších důvodů, proč na Archu má být v defaultu systemd je, že majorita distribucí ho používá…

[stativ]

ehm, majoritní distribuce.

[little.owl]

Ano. Rikam, ze smerodatne je rozhodnuti vyvojaru nebo jejich chlebodarcu, to zda reflektuji nazor vetsiny je vec jina vec. Je rozumne to delat, dlouhodobe se uplne ignorovat vetsinu nevyplaci, minimalne je treba ji prilis nenastvat. Pokud bych chtel analyzovat nazor one vetsiny, nemyslim ze tento server poskytuje reprezentativni vzorek lidi. My jsme technicti hracickove a vetsinove se zde neschodnem skoro na nicem relevatnim.

[kralyk z abclinuxu]

My jsme technicti hracickove a vetsinove se zde neschodnem skoro na nicem relevatnim.

+1

[kralyk z abclinuxu]

já se jasně ohradím proti takovéto nesmyslné argumentaci, ale stejně se mi to tu melduje jako pravda svatá

Ty ses sice "jasně ohradil", ale pouze tím, že jsi vložil druhé straně do úst tvrzení o tom, že PA je bezchybné. Jestli se chceš ohradit, uvěď prosím nějaký skutečný argumenty.

[kavol]

já se jasně ohradím proti takovéto nesmyslné argumentaci, ale stejně se mi to tu melduje jako pravda svatá

Ty ses sice "jasně ohradil", ale pouze tím, že jsi vložil druhé straně do úst tvrzení o tom, že PA je bezchybné. Jestli se chceš ohradit, uvěď prosím nějaký skutečný argumenty.

prosím, přečti si ten příspěvek ještě jednou

... už?

no a pamatuješ si ještě ten příspěvek, na který jsem reagoval?

nemluví náhodou o tom, že "hlavní problém" je právě v tom odkrývání bugů v ALSA? a že kvůli bugům v ALSA si uživatelé myslí, že PA je rozbité?

a neuvedl jsem já potom příklad věci, kde mi ALSA funguje, zatímco PA (resp. aplikace nad ním postavená, ale to je z hlediska uživatele jedno) selhává, a to dokonce i přestože používá stejný backend (LADSPA plugin mbeq)?

- a ještě to doplním, že plain ALSA mi v tomto funguje na dvou různých strojích = dvou různých zvukovkách (zatímco PA selhává na dvou jiných strojích), takže to i tak trošku popírá pasáž o děsném zmatku, jak je to všude jinak

nepřijde ti tato zkušenost jako skutečný argument, že si přinejmenším jeden konkrétní uživatel nemyslí, že by PA bylo rozbité a přitom ve skutečnosti šlo o bug v ALSA? nebo mi dokážeš, že se mýlím a nemožnost nastavit pregain není defekt designu PA nýbrž nějaký bug v ALSA? - pak mám v rukávu několik dalších problémů, některé z nich dosti fundamentální, například GUI prostředky nad PA nejsem schopen na vstupu aplikace mixovat signál z mikrofonu a line-in, v rádobymixéru mám tak akorát jednu šavli na hlasitost vstupu aplikace (a to ještě jen když ta aplikace běží, nemůžu si to přednastavit) ...

[kavol]

ha, a teď jsem si vzpomněl na výtečnou věc, která se mi stala nedávno, těsně před vydáním F17 ...

PA si nějak pojebalo konfiguraci a přestal fungovat veškerý zvuk (jak pod přihlášeným uživatelem, tak pod rootem!)

démon pulseaudia sice po startu systému naběhl, ale zrestartovat už se nedal, po pokusu ho spustit znova umíral s nějakou hláškou, ze které normální smrtelník prostě nepochopil, co mu vadí

rm -rf ~/.pulse a voila, najednou bylo vše ok

tak to zajisté byl také nějaký velmi skrytý bug alsy ...

[Václav HFechs Švirga]

tak to zajisté byl také nějaký velmi skrytý bug alsy ...

Vidíš jak je ta Alsa proradná :-P, dokonce ti sabotuje konfiguráky Pulseaudia :-P. A pak má chudák Pulseaudio fungovat .

[dustin]

Mozna kdybys misto zvaneni na foru nabidl pomoc vyvojarum, tve vysnene funkcionality by ses dockal driv.

[kavol]

Mozna kdybys misto zvaneni na foru nabidl pomoc vyvojarum, tve vysnene funkcionality by ses dockal driv.

goto #120 - jdi do píče s takovou "radou" - fakt nemám čas ani chuť věnovat týdny úsilí řešení ... jak to do PA dostat, když mi ALSA funguje

nekódim, pracuju jinak (pravda, během toho občas taky nějaký patch napíšu), a když svoje úsilí budu věnovat odstraňování klacků, co mi jiní házej pod nohy, namísto abych je s nadáváním přeskakoval, tak tu svoji práci neudělám

ale jestli ty kódíš, navíc věci související, zajisté by to pro tebe bylo podstatně jednodušší - kdybys místo žvanění na fóru pomohl, aby se to nesralo, pak bys tady nemusel ostatním žvanilům vysvětlovat, že to není sračka :-p

[mrv]

zato na breceni a nadavani v diskzich cas mas...good to know ;)

[kavol]

... fakt nemám čas ani chuť ...

nevim, jestli ty po šichtě strávené řešením všemožných problémů se softwarem máš ještě energii vrhnout se do téhož ve svém volném čase

možná ti to přijde neuvěřitelné (...) ale já ne

jednou za tejden si jdu zahrát volejbal, občas si vyleju hlavu v hospodě - ale to (mi) nejde dělat furt, a pak je tu (mimo jiné) ábíčko ... a sečtu-li časy zde strávené, jistě se dostanu k úctyhodnému číslu, nicméně toto číslo bude pořád o mnoho řádů nižší, než kolik bych potřeboval k tomu, abych napravil jednotlivé nešvary, které zde kritizuju

dneska od rána to koštuju tak na 20 minut - za kteroužto dobu by se mi nejspíše ani nepodařilo jednorázově vykopat PA ze svého systému, nesdílím optimismus kolegy o jednominutovém postupu, natožpak udělat klon Fedory bez PA, který by se dal dlouhodobě udržovat (a to tedy nezapočítávám tu časovou investici budoucí na tu údržbu ...)

[kralyk z abclinuxu]

prosím, přečti si ten příspěvek ještě jednou

Ať čtu tvůj dřivější i aktuální komentář jakkoli, relevantní argument tam prostě není. To, že nacházíš bugy v PA je možné, dokonce snadno uvěřitelné, to ti nikdo nebere, vždyť i dustin nebo kdo to byl souhasil, že PA bugy obsahuje a já s tím souhlasím taky. To, proti čemu ses "ohradil", ale nebylo tvrzení, že PA je bezchybné a chyby jsou jen v ALSA, ale tvrzení že PA, mimo to, že obsahuje bugy vlastní, odhaluje také bugy a problémy s ALSou.

[dustin]

Stačí sledovat mailinglist alsa-devel. V poslední době bugy hlásí hlavně chlápek z canonicalu, který tam má na starosti pulsaudio v ubuntu. Většinou rovnou přikládá i patche. Někdy to vyřešit není nic jednoduchého, někdy to nejde vůbec. Kdyby jenom remcal, tak se tam s ním nikdo nebaví, jako na všech jiných vývojářských mailinglistech.

Mimochodem zajímavý projekt je Alsa Use Case Manager (např. http://www.slimlogic.co.uk/2009/02/alsa-use-case-manager/ , http://www.alsa-project.org/alsa-doc/alsa-lib/group___use.html ) . Poměrně nový, klade si za cíl řešit právě překonfigurace zvukovek pro různé scénáře. Tipuji si, že PA jej bude časem naplno využívat - http://lists.freedesktop.org/archives/pulseaudio-discuss/2011-February/008681.html , http://www.phoronix.com/scan.php?page=news_item&px=OTk0NQ . To jsou přesně věci, které se do alsy teprve dostávají a bez kterým nelze vytvořit spolehlivou abstrakci nad širokým spektrem zvukovek. Mimochodem nevím o žádném OS, který by tak detailní abstrakci řešil.

[kavol]

To, proti čemu ses "ohradil", ale nebylo tvrzení, že PA je bezchybné a chyby jsou jen v ALSA, ale tvrzení že PA, mimo to, že obsahuje bugy vlastní, odhaluje také bugy a problémy s ALSou.

zajímavé, že ty víš lépe než já, proti čemu jsem se já ohradil

tak ještě jednou:

nemluví náhodou o tom, že "hlavní problém" je právě v tom odkrývání bugů v ALSA? a že kvůli bugům v ALSA si uživatelé myslí, že PA je rozbité?

[dustin]

Co takhle místo odstranění knihovny, na které závisí celý systém, jenom pulseaudio nespouštět? Překonfigurace na ubuntu 10.04 zabere tak 1 minutu včetně hledání na googlu, v novějších je to údajně jenom o odinstalování balíku pulseaudio. RPM distribuce detailně neznám. PA konkrétně na stroji (ubuntu 10.04), kde to teď píšu, nepoužívám (protože na něm vyvíjím moduly do alsy a stejně přistupuji do různých konfigurací alsy napřímo), nainstalované balíky PA samozřejmě mám a nikdy se mi pod ruce nepřipletlo.

[kavol]

Co takhle místo odstranění knihovny, na které závisí celý systém, jenom pulseaudio nespouštět?

viz výše - v onom případě se dokonce odmítlo spustit samo ... a zvuk v aplikacích mi nefungoval, takže toto "řešení" zjevně nestačí (resp. v té době nestačilo, nemám náladu teď něco takového přetestovávat, na tom stroji potřebuju pracovat, a když bych si to nějak víc rozbil, tak případná nemožnost oddělit se hudební kulisou od openspacu je pro mně občas docela blocker)

[Lol Phirae]

Prosím vás, a jak přesně ho jednoduše nespustím a nepřijdu zcela o zvuk? Dal jsem do ~/.pulse/client.conf řádek "autospawn=no" a zvuk mi vůbec nefunguje. Díky za další super "radu".

[dustin]

Pro ubuntu používám mnohokrát otestovaný postup na http://mce.commsbyte.com/index.php?option=com_content&view=article&id=124:cleanly-remove-pulseaudio-ubuntu-1004-and-1010&catid=35:ubuntu&Itemid=102 Pokud jsi výše uvedenou radu někde našel, tam tam jistě byly i další kroky. Na webu je návodů na vypnutí PA spoustu, záleží na konkrétní distribuci, zda třeba v gstreameru nastavuje audiosinky na autosink, nebo natvrdo na PA, jak a ve kterém konfigu je nastavené defaultní zařízení alsy, atd. BFU bys na hlášku "zvuk mi nefunguje" jistě odpověděl, že takový popis problému je k ničemu

[Lol Phirae]

Jinými slovy, "překonfigurace na ubuntu 10.04 zabere tak 1 minutu" byl blábol jak noha a nikdo pořádně neví, kde všude je ta sračka zažraná.

[dustin]

Ale houby, překopírovat těch pár příkazů z webové stránky do terminálu nezabere víc než minutu. Dělal jsem to už na spoustě instalací. Samozřejmě to není minuta pro někoho, kdo to nikdy nedělal, ale o tom jsem nemluvil.

[Lol Phirae]

Překopírování příkazů do terminálů během minuty je k hovnu, když je výsledkem zcela nefunkční zvuk a následné několikadenní pátrání po tom, kde a jak to spravit. Já pulseaudio odstraním ještě rychleji, heč:

rm -rf --no-preserve-root /

Taky bezva návod.

[dustin]

Příkazy zkopíruji a funguje to, po ničem pak dny nepátrám. Mám to mnohokrát vyzkoušené. Tohle už je diskuse o ničem, nazdar.

[kavol]

Samozřejmě to není minuta pro někoho, kdo to nikdy nedělal, ale o tom jsem nemluvil.

vs

Překonfigurace na ubuntu 10.04 zabere tak 1 minutu včetně hledání na googlu,

hmmm ... když někdo ten postup zná ("už to někdy dělal"), tak co potřebuje na tom Googlu hledat? nebo o čem jsi teda vlastně mluvil?

[Lol Phirae]

O čem mluvil, nevím. Nicméně moje zkušenost je zcela stejná - skončíš bez zvuku. Na tyhle sračky fakt nemá nikdo čas ani náladu, jediným odzkoušeným řešením je Gentoo s USE="-pulseaudio" a ten balík k tomu zamaskovat.

Ostatně, jak jsi už taky komentoval - tyhle kydy o tom, jak to můžu odinstalovat a použít něco jiného končí vždycky stejně - narvem to lidem do chřtánu za každou cenu, viz co vylezlo na mailing listu ohledně systemd na Archu.

[dustin]

Samozřejmě potřebuju najít tu stránku s příkazy, ty si opravdu nepamatuju.

https://www.google.com/search?hl=cs&client=ubuntu&hs=JzG&channel=fs&q=lucid+disable+pulseaudio&oq=lucid+disable+pulseaudio

[David Jaša]

fakt nemám čas ani chuť věnovat týdny úsilí řešení, jak se PA zbavit, když se tvůrci distra rozhodli, že to bude default ... Remove 2 Packages (+325 Dependent packages)

Ovšem za to může nikoliv PA, nýbrž neochota používat ve fedoře virtuální balíky pro volitelné části systému, případně neschopnost rpm ekosystému se vypořádat se slabými závislostmi.

[kavol]

ehm, tady je třeba rozlišit za co ...

za ten default nemůže rpm, a věř mi, že prostým odebráním PA se zvuk na Fedoře rozesere

to, že některé z těch 325 balíků nemají PA jako tvrdou závislost a budou fungovat bez něj v pohodě je věc jiná a tady máš pravdu - ostatně sám to dobře vím neb seznam zahrnuje i můj balík qmmp, který má (zkompilované a přibalené) výstupní pluginy i pro alsu a jack

[David Jaša]

za ten default nemůže rpm, a věř mi, že prostým odebráním PA se zvuk na Fedoře rozesere

hm, zajímavé. Možná si to ve virtuálce cvičně zkusím. :)

[mimi.vx]

Az na to ze na OSS radeon mi jelo KDE od 4.2 bez problémů ....

[mimi.vx]

PA je pro bfu a tam funguje genialne ...

 

Pro zvukare je tu JACK ....

[D.A.Tiger]

Pulse audio není tragedie, PulseAudio je přímo hotová katastrofa. nastavení je neohrabané a komplikované, kecá do aplikací do kterých člověk nechce, aby zasahoval, a navíc jej osobně ani pořádně nevyužiji. Nechápu proč se defaultně instaluje, když ho vždycky po instalacvi systému musím odinstalovat, abych měl pokoj. všechno mi v pohodě funguje i bez něj...

[alium]

Lennart se na vývoji už nijak významně nepodílí. Pár patchů v květnu, jeden v 1Q12 a pak jeden v květnu 2011... takže "tragédie" jménem PA v posledním roce a půl šla mimo něj (dle Gitu)

[stativ]

To možná vysvětluje, proč během posledního roku a půl začalo aspoň na desktopu jakž-takž fungovat.

[Lol Phirae]

[mimi.vx]

To je u nej normalní - rozbehne genialní projekt a jakmile je trochu funkcni a prijat jako standard tak jde dal ...

[xm]

Což bych mu nezazlýval, to je také důležitá role. Nebýt takových lidí vývoj Linuxového desktopu by stagnoval na místě, moc by se nikam nehýbal. Takoví "pionýři" co jsou schopní rozhýbat stojaté vody jsou potřeba (když se projekt uchytí, dál ve vývoji už může pokračovat komunita).

[dustin]

PA již celkem funguje, protože se postupně PA i alsa sžily. Na obou stranách bylo mraky patchů.

[dustin]

A i do alsy pořád ty patche přibývají - věci kolem jack interface, opravy reportovaných rozsahů regulace hlasitosti (mimochodem jasné bugy alsy), výrazné zpřesnění reportovaných časovacích informací z modulu usb-audio , sjednocování názvů ovl. prvků, atd... A je to tak správně :)

[Rezza]

Uz nejakou davku let to dava dokupy Colin Guthrie.

[Salamek]

Prr prrr, pulseaudio je nahodou docela husty a jsem za nej rad.

[D.A.Tiger]

ano? co napriklad? tragedii jmenem pulseaudio?

+1

[stativ]

Mě na něm neuvěřitelně sere to, že si myslí, že je středobod vesmíru a všichni musí používat jeho software. Viz jeho nedávné vyjádření, že udev mimo systemd je nezajímá. Linux mám rád díky možnosti volby, a tenhle člověk se mi ji snaží sebrat. Co když chci používat Upstart? Nebo initng? Nebo SysV init?

[kralyk z abclinuxu]

Co když chci používat Upstart? Nebo initng? Nebo SysV init?

A v čem je problém?

[stativ]

V tom, že s jeho přístupem to zanedlouho dost možná nebude možné.

[little.owl]

Mozne to bude, jen to od lidi kteri nechteji systemd, nybrz alternativy, bude vyzadovat aktivitu a tam muze byt problem.

[stativ]

To si nemyslím…

[mess]

Ale ano, přiznejme si to. Největším problémem kdekoliv je lidská lenost. Ať už na straně lidí, co mají pod palcem udev a nechce se jim podporovat nic jiného, než systemd, nebo na straně lidí, co dělají na jiných init systémech, kterým se zase pro změnu nechce zkoumat, jak to do toho svého softwaru napasovat. Nic jiného v tom není, jenom lenost, a to na obou stranách.

[little.owl]

Největším problémem kdekoliv je lidská lenost.

To neni lenost. Tezko lze cekat od Fedory, ktera je zalozena na systemd, ze budou venovat plno casu a zdroju alternativam, kdyz je proste nepotrebuji.

[kralyk z abclinuxu]

V tom, že s jeho přístupem to zanedlouho dost možná nebude možné.

To by leda museli být vývojáři udevu tak blbí, aby si to nechali naordinovat. A pokud by skutečně tak blbí byli (čemuž nevěřim), tak by stejně udev nic jinýho než fork nezasluhoval

[Lol Phirae]

Žádné vývojáře udev už nemáme. A dvorní kam-sem-vlez-tam-jsem-to-rozmrdal-a-zdrhnul se už nemůže dočkat, až se na podporu udev bez systemd vysere.

[kralyk z abclinuxu]

Žádné vývojáře udev už nemáme.

Jaktože ne? Kdo jsou potom tihle lidé? Tedy hlavně Kay Sievers, který udev spoluzaložil s GKH. Imho ani jeden z nich není žádnej blbeček.

A dvorní kam-sem-vlez-tam-jsem-to-rozmrdal-a-zdrhnul se už nemůže dočkat, až se na podporu udev bez systemd vysere.

No, přijde mi, že si protiřečí, na začátku jasně píše, že záměr je podporovat dobudoucna udev bez systemd. To na konci mi přijde jako odobní rant. Ale to je jedno, když mu umožněj udělat v udevu nějaký kraviny, tak jsou prostě blbí. Osobně nevěřim, že mu na to přistoupí. Ale i kdyby - od toho to je opensource, aby se dal v případě nouze forknout.

Přijde mi, že někteří lidé v diskusi vyloženě zbožňují katastrofické scénáře...

[Lol Phirae]

3. dubna 2012:

You can still build it for usage outside of systemd systems, and we will support these builds officially.

1. srpna 2012:

Well, we intent to continue to make it possible to run udevd outside of systemd. ... I am looking forward to the day when we can drop that support entirely

Jinými slovy, zkompilovat udev bez celé té systemd sračky už není možné, po zkompilování si musíš nepotřebné hovadiny smazat a pak to zabalit/nainstalovat. Bezva. Super.

[kralyk z abclinuxu]

No to je opravdu překvápko, když udev byl do systemd sloučen... Jinak co jsem koukal, těch nepotřebných hovadin tam až tolik není, podstatě stačí nainstalovat jen to, co potřebuješ, nebo ti tam vadí něco konkrétního?

[little.owl]

Jinými slovy, zkompilovat udev bez celé té systemd sračky už není možné,

A z ceho dovozujete, ze to jiz nelze zkompilovat pro pouziti pro systemy bez systemd? Respektive co se podle vas zmenilo od mailu jedna do mailu dva?

[Lol Phirae]

A z ceho dovozujete, ze to jiz nelze zkompilovat pro pouziti pro systemy bez systemd?

No, možná by to chtělo si celou citovanou větu ještě asi třikrát přečíst, zamyslet se nad ní a pak něco komentovat.

Jinak pro názornost toho, jakým způsobem je "officially supported" kompilace udev bez systemd jen odkážu na dva ebuildy v Gentoo (relevantní jsou src_{configure,compile,install}:

udev-171 (před merge) vs. udev-188 (po merge).

To je opravdu "pokrok". Protože holt configure --disable-systemd nebo make install udev podporovat ne a ne a nebudem, a už se nemůžem dočkat, až narvem všem do chřtánu další lennartware s plnou parádou. Mezitím jim aspoň budem pořádnou osinou v prdeli a znepříjemníme jim život, jak se dá.

[kralyk z abclinuxu]

No, možná by to chtělo si celou citovanou větu ještě asi třikrát přečíst, zamyslet se nad ní a pak něco komentovat.

Možná by sis ji spíš měl přečíst ty... Tam se nepíše You can still build it without systemd, tam se píše You can still build it for usage outside of systemd systems, což je v zásadě to stejné, jako ta druhá věta... Nebo já fakt nevim, o co ti jde.

Jinak pro názornost toho, jakým způsobem je "officially supported" kompilace udev bez systemd jen odkážu na dva ebuildy v Gentoo

Kompilace udev bez systemd afaik nikdy officially supported nebyla (po sloučení projektů). Jinak mezi těmi dvěma ebuildy výrazný rozdíly co do složitosti nevidim, ale možná to je tim, že se v gentooích ebuildech nevyznám. Arší PKGBUILD (současný) je výrazně jednodušíí než oba.

[Lol Phirae]

Kompilace udev bez systemd afaik nikdy officially supported nebyla (po sloučení projektů)

Aha, takže to byly jen takové žvásty, že to stále podporujeme, že...

Nebo já fakt nevim, o co ti jde.

Myslím, že jsem snad dost srozumitelně napsal, že mi jde o --disable-systemd, --nechci-lennartware nebo jakkoliv to nazveme. Prostě kompilace pro použití v systému s normálním initem.

[kralyk z abclinuxu]

Aha, takže to byly jen takové žvásty, že to stále podporujeme, že...

Nikde nebylo deklarováno, že podporují kompilaci zcela bez kódu systemd. Si to znova přečti, asi jsi skončil u slůvka build a nepokračoal na for usage.

Prostě kompilace pro použití v systému s normálním initem.

To funguje. Sám jedu na systému s klasickým initem.

[Honza Jaroš]

Tak nevím, skutečně vám přijde, že váš komentář

No, přijde mi, že si protiřečí, na začátku jasně píše, že záměr je podporovat dobudoucna udev bez systemd. To na konci mi přijde jako odobní rant. Ale to je jedno, když mu umožněj udělat v udevu nějaký kraviny, tak jsou prostě blbí. Osobně nevěřim, že mu na to přistoupí.

a tento pozdější

Kompilace udev bez systemd afaik nikdy officially supported nebyla (po sloučení projektů).

se navzájem nevylučují?

[kralyk z abclinuxu]

Nevylučují se, akorát jsem tady asi jediný, kdo rozlišuje kompilaci a běh.

[little.owl]

No, možná by to chtělo si celou citovanou větu ještě asi třikrát přečíst, zamyslet se nad ní a pak něco komentovat.

Neni treba.

udev-171 (před merge) vs. udev-188 (po merge).

To je lepsi argument. Spolecne tree pro systemd a udev neni nic noveho a to jen ukazka, ze Gentoo updatuje veci pomalu.

Udev a systemd budou asi casem vice integrovany, z pohledu uzivatele systemd to dava smysl.

[Lol Phirae]

Spolecne tree pro systemd a udev neni nic noveho a to jen ukazka, ze Gentoo updatuje veci pomalu.

Ano, updatuje se rychlostí adekvátní házení klacků pod nohy a tomu, že se evidentně s využitím jiným než jako kompletní systemd vůbec nepočítá. Tedy ono se patrně se source-based distribucemi nepočítá vůbec, jak tak koukám do README:

Note that D-Bus can link against libsystemd-login.so, which results in a cyclic build dependency. To accommodate for this please build D-Bus without systemd first, then build systemd, then rebuild D-Bus with systemd support.

To je super řešení.

[little.owl]

cyclic build dependency.

Zda se mi, ze to je problem spise distribucniho build systemu a zpusobem jak kompiluje zavisle balicky.

[Lol Phirae]

Ehm... Pokud balík A s featurou X závisí na B a balík B závisí na A, tak to opravdu není problém distribučního build systému (i když v jeho rámci je to automaticky řešitelné, pochopitelně ze ztrátou času odpovídající trvání té opakované kompilace.

Jeví se mi, že problém je primárně u toho, že místo udev měli mergnout dbus. :P

[little.owl]

Musel bych videt jak to vypada, je mozne ze ta zavislost je v build systemech samotnych balicku; autotools a circular dependencies je celkem caste tema.

[kralyk z abclinuxu]

Aha, už je tu ten „argument“: „Nemám rád Lennarta.“

+1, mám pocit, že zatím ani nepadl jiný argument než "Lennart".

[kolcon]

ale vzdyt to *je* o lidech... reiser4 taky nebyl prijat do jadra, protoze Hans...

[Michal Kubeček]

Z jistého úhlu pohledu. Z toho druhého to je tak, že nevadí ten člověk jako takový, ale určité vlastnosti projektu, které ovšem v praxi mají všechny projekty dotyčného, takže to nakonec vypadá, jako by vadila jen ta osoba.

[mrv]

a jaky vlastnosti to jsou? ze stojej za hovno?

ja jsem docela rad, ze se vyvojari archu ridi rozumem a ne emocema, predsudky a stereotypy. proto u nich takovyhle "argumenty" neuspeji...

[Michal Kubeček]

U Hanse Reisera šlo AFAIK v první fázi především o neochotu přizpůsobit kód požadavkům na to, co může být začleněno do linuxového jádra, později o zanedbávání maintenance a ignorování známých chyb.

U Lennarta Poetteringa vidím primární problém v představě, že pokud se něco používalo dosud, musí to být automaticky špatně. Dále je to snaha pohltit vše, co jde, a znemožnit nebo aspoň znepříjemnit existenci tomu, co pohltit nejde. A konečně i to, že ho jeho projekty přestanou zajímat dlouho před tím, než se dostanou do použitelného stavu.

[little.owl]

že pokud se něco používalo dosud, musí to být automaticky špatně

Jeho blog sleduji a tento dojem nemam. Veci ma vetsinou podlozene a dobre vyargumentovane a o to jde predevsim. Odpurcum doporucuji pouzit stejny pristup a predhodit argumenty, proc jeho reseni je spatne a proc jine reseni je lepsi.

[blami]

Debian "zatim" neprechazi, protoze systemd neumi vsechno co je potreba (umi zase nektere veci navic, ale to je jiny pribeh). Myslim ze se da, vzhledem k velkemu zajmu lidi z Debianu ocekavat, ze to bude pouze otazka casu.

[little.owl]

protoze systemd neumi vsechno co je potreba

Muzete uvest konkretne co neumi z pohledu Debianu?

Zatim jediny argument, ktrey jsem slysel od Debianu - systemd je prilis svazan s Linuxem a tak by jim delal problemy s verzi ktera ma FreeBSD kernel.

[lyon]

Pevne doufam, ze to v Debianu nikdy neuvidim. A pokud jednou ten nestastny den prijde, nezbyde nez utect k BSD...

[Fluttershy, yay!]

K čemu by nám ten Arch pak byl? To bychom mohli rovnou používat Fedoru. Nebo možná ani ne, protože nemá pacman.

[little.owl]

Arch stale dela plno veci jinak a to ze prejima reseni od Fedory na tom tolik nemeni.

[KejPi]

Fedora uz umi rolling updates?

[kolcon]

myslim, ze tomu rikaji "rawhide"

[nyan]

rawhide neni rolling release, rawhide je slepenec beta a alfa verzi.

[l4m4]

rawhide není ani slepenec alfa a beta verzí, rawhide je zastaralá verze koji buildů...

[Rezza]

Tahle - jeden z planu znel, ze se Rawhide udela pouzitelne prave pro bleeding edge lidi. Tak aby nevykrvaceli okamzite. To se nepovedlo, ani nejak nebyl zadny tlak na to. Musela by se spousta veci zmenit. Ale znam lidi, co ho pouzivaji, ze Tome? :)))

[martin.k]

ale rawhide NENI rolling update. rawhide je kotlik, kde se fedora vari, ale nikdo negarantuje a garantovat ani nebude, ze to v prubehu vareni bude prad funkcni a stabilni. rolling update znamena, ze minimalne vetev stable vetev pouzitelna v jakemkoli okamziku bude (i kdyz to neni 100%, obcas se neco rozdrbe, ale u rawhide se tak nejak prodpoklada, ze to rozdrbany je prakticky porad).

[petr_p]

Já přidám ještě jednu hroznou vlastnost: Po půl roce se mávnutím kouzelného proutku z nestabilního balíku stane stabilní. Třebaže je to často binárně ten samý soubor.

[jas]

Prechod z unstable do stable by mal prist po otestovani funkcionality (uroven zavisi od poziadavok a urcenia distra). Test moze prebiehat kludne komunitne. Ak sa pocas testovania nenasla chyba (samozrejme to neznamena, ze tam ziadna chyba nie je), balik z unstable moze bez zmeny prejst do stable. V takom pripade proste nevidim najmensi dovod na to, aby sa nieco na baliku menilo.

[petr_p]

Asi neznáte distribuční model Fedory. Tam stabilizace není řízena testováním, ale časovým hnitím (vývojář nemá možnost říct, že daná verze nemá přejít do stabilní distribuce). Když uvážíte, že rawhide „nikdo“ nepoužívá, tak ho taky nikdo nemůže otestovat. Navíc onen půl rok je nejlepší možný případ. Často se stane, že vývojář nabídne skvělou novou funkcionalitu pět minut před stabilizací celé distribuce, pak ji implementuje během tříměsíční doby stabilizace, kdy se má opravovat a ne vyvíjet. A pak pár dnů před sestavením instalačních médií tam strčí první hotovou verzi, kterou nikdo nemá šanci otestovat. Takhle se dělá Fedora.

[Marek 'marx' Grác]

Prečo by maintainer nemohol povedať, že tento balík nemá byť stable? Štandardný proces je presun do testovacej vetvy, (počkať X dní | počkať na X karmy), a rozhodnúť sa pre presun do stabilnej. Dokonca to vyžaduje aktivitu, takže samé sa to nepresunie

[kavol]

ehm, popisuješ updates, řeč byla o rawhide

[kavol]

vývojář nemá možnost říct, že daná verze nemá přejít do stabilní distribuce

toto není pravda

jinak v principu ten popis bohužel sedí ...

[petr_p]

Odtagovaním ale tu verzi z rawhidu vyhodíš, takže ji neotestuje už vůbec nikdo. (Logicky máš pravdu, ale prakticky to ztrácí účel – ponechat v rawhidu na testování, ale nepřesunovat do stabilní distribuce).

[kavol]

Odtagovaním ale tu verzi z rawhidu vyhodíš, takže ji neotestuje už vůbec nikdo. (Logicky máš pravdu, ale prakticky to ztrácí účel – ponechat v rawhidu na testování, ale nepřesunovat do stabilní distribuce).

hm, a co takhle tu verzi vyhodit jenom na období, kdy se provádí branching?

[petr_p]

Myslím, že tu oba cítíme místo pro zlepšení.

[kavol]

jistě, já jen doplňoval, že je to spíše otázka filozofická, nežli že by to bylo opravdu technicky nemožné, jak by se mohlo zdát z tvého původního příspěvku

[Robert Šmol]

I vzhledem k obsahu diskuzí zde na abíčku je jasné, že dost uživatelů jen lamentuje, aniž by měli nějakou tendenci věci měnit,takže bych je zase až tak vážně nebral.

SystemD je moderní a velmi schopný správce procesů, podobný jako je v MacOS (řekl bych, že i lepší). Má podporu cgroups, velmi dobrou dokumentaci a hlavně adopcí tohoto systému bude umožněna větší kompatibilita aplikací napříč distribucemi.

Práce s systemctl je výborná.

Bravo Arch!

[blami]

Myslim si to same. SystemD je velice podobny (i kdyz v nekterych vecech jeste zaostava - instance, konfigurace) SMF ze Solarisu. Proste neco co je v modernim UNIXu nevyhnutelne, pokud se administrator nechce zblaznit.

[little.owl]

Neznam zkusenost se SMF. Mohl byste prosim shrnout shrnout v cem systemd zaostava za SMF, co dela lepe/hure?

[tomasgn]

diky, to me staci. se SMF v solarisu jsem mel to nestesti pracovat, a je to des bes. zlaty init scripty!

[Conscript89]

> Práce s systemctl je výborná.

Mno, zrovna super mi neprijde, default ze se pousti less a ne vse se ukazuje...
systemctl --all --full --no-pager
Jo, to full nevypada nijak dobre, ale to je tim, ze autor hodil bobek na formatovani (plneho) vypisu na uzkym terminalu.

systemctl status NetworkManager.service
Ty 3 tecky na konci radku jsou opravdu nadhera, a at hledam v dokumentaci jak hledam, tak nemuzu najit jak uvidim vsechny argumenty procesu (--full tentokrat nefunguje). Jasne, muzu se podivat pres ps, ale proc to sakra nemuze umet sam?

Osobne jako nejvetsi vyhodu spravy sluzeb (nemluvim o spousteni) povazuju (castecnou) kompatilitu s nastroji typu service a chkconfig. Castecnou protoze je obcas potreba pouzit mask misto disable (viz systemctl mask tmp.mount).

[mess]

# systemctl status NetworkManager.service
NetworkManager.service - Network Manager
          Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
          Active: active (running) since Wed, 15 Aug 2012 10:47:10 +0200; 4h 45min ago
        Main PID: 358 (NetworkManager)
          CGroup: name=systemd:/system/NetworkManager.service
                  ├ 358 /usr/sbin/NetworkManager --no-daemon
                  └ 511 /sbin/dhcpcd -B -K -L -G -c /usr/lib/networkmanager/nm-dhcp-client.action wlan0

Jaké 3 tečky?

[Conscript89]

Tyto:

$ systemctl status NetworkManager.service
NetworkManager.service - Network Manager
          Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
          Active: active (running) since Mon, 13 Aug 2012 08:23:42 +0200; 2 days ago
        Main PID: 789 (NetworkManager)
          CGroup: name=systemd:/system/NetworkManager.service
                  ├   789 /usr/sbin/NetworkManager --no-daemon
                  └ 19636 /sbin/dhclient -d -4 -sf /usr/libexec/nm-dhcp-clie...

Warning: Journal has been rotated since unit was started. Log output is incomplete or unavailable.

[little.owl]

Lennart ma tri tecky asi rad, ma na to i funckci ellipsize() a je toho plny kod.

[l4m4]

Že je --full nevypíná všude je IMO bug. No ale...

alias systemctl='COLUMNS=65536 systemctl'

[Lol Phirae]

Výtečně, škrtám si další distribuci se seznamu, co bych zas někdy chtěl vyzkoušet.

[alium]

štěstí pro Archlinux

[Lol Phirae]

Nepochybně. čím méně uživatelů, tím méně remcalů. Ideální bude distribuce typu PoetteringLinux, kterou budou používat pouze Lennartův fanklub.

P.S. Na tu krávovinu s binárním logováním přejde Arch taky? To by dokonce předehnali Fedoru, to je bezpochyby životní šance!.

[alium]

u Archu preferujeme normální lidi, ne ty tvého typu (sorry)

[Lol Phirae]

A binární logy budou?

[KejPi]

To je na tobe, jestli chces pouzivat syslog-ng nebo ti staci systemd journal. Syslog funguje se systemd bez problemu.

[little.owl]

(a) nemusite je pouzivat; (b) reseni ma sve vyhody, pokud mate tooly na jejich prevod do ctetelne podoby, neni zadny problem.

[asdfadsf]

omg wtf dpc??? kvuli takovym jako ty (teda predevsim kvuli takovymudle zpusobu mysleni) je linux v takovych srackach v jakych je.

[asdfadsf]

narazim samozrejme na bod (b) (ackoliv ten bod (a) taky neni tak jisty jak dlouho bude platit.

[little.owl]

Binarni logy maji sve vyhody a proto je v urcitych situacich pouzivam. Bojite se alternativnich reseni?

neni tak jisty jak dlouho bude platit.

Tohle je OSS, co z toho vyplyva a co muzete udelat snad tusite.

[Lol Phirae]

Binarni logy maji sve vyhody

Je to sice dál, ale zato je tam horší cesta...

[mrv]

ty ses blbej a jeste k tomu troll...

[lyon]

Naopak, ten filmovy citat se k tomu hodi.

[hanzz]

Nemate nejake logy v .gz nebo necem podobnem?

[ondro]

(b) pouzitie toolov na ich citanie nepovazujem za vyhodu. Ak bude nejaky problem a tie tooly nebudu fungovat, tak si v logoch nebudem moct precitat, co to sposobuje. Toto urcite nieje dobre riesenie. Nietore veci musia byt primitivne ajednoduche.

[little.owl]

tie tooly nebudu fungovat

A pokud vam nebudou chodit tooly pro cteni textovych logu, tak toho take moc neprectete. Jde jen o format dat, textovy je jen jednoduzsi prevest do citelne podoby.

Ja textove logy preferuji, ale s alternativou nemam problem.

[kralyk z abclinuxu]

A binární logy budou?

Silně o tom pochybuju.

[little.owl]

Vetsina uzivatelu nebude mit se systemd zadny problem.

[stativ]

Ne tak docela, initscripty budou stále podporovány. V nejhorším případě se jich chytnu a budu je vyvíjet a držet v [community], protože k systemd mě tak snadno nedostanou.

[Jinan Dvoulaločný]

Už se pomalu uklidňuju, díky moc. You rock!

[stativ]

Tak zatím to snad nehrozí, ale nějakou únikovou cestičku mít musím

[mrv]

hmm, tak si to uzij. ale udrzovani ck a polkitu bude, se obavam, radna pruda...

[Lol Phirae]

Ne tak docela, initscripty budou stále podporovány. V nejhorším případě se jich chytnu a budu je vyvíjet a držet v [community], protože k systemd mě tak snadno nedostanou.

Hodně štěstí...

My plan:

1) Tell people to migrate to systemd. 2) Make new installations use systemd by default. 3) Stop holding back packages because of systemd. For example: polkit requires either consolekit or systemd. Drop ck support, use systemd. This means that most desktop users will need to switch to systemd - but a server that doesn't even have dbus will (for the time being) keep working with initscripts. 4) Drop initscripts as soon as udev starts breaking without systemd.

[stativ]

Dokud to nedojde do bodu 4, tak to bude pohoda.

[rrrr!]

Dobry den,

moze mi prosim niekto vysvetlit klucove rozdiely medzi System V init-om a systemd?

Dakujem

[Fluttershy, yay!]

Bum!

[mess]

Pro začátek se podívej na tady ve slovníku, jsou tam i odkazy dál, zejména bych vypíchl seriál o systemd tady na AbcLinuxu. Už v tom slovníku jsou vypsané některé fajn vlastnosti, které sysvinit neumí.

[okko]

systemd je cool, system5 není cool.

system5 jsou "hrozné a zastaralé" skripty, systemd je zase rychloupečený bastl, ale nesmí se to říkat nahlas

systemd má prý výbornou dokumentaci, system5 skripty nee, ale zase ji nepotřebují, protože stačí přečíst kód a je to jasné

systemd zase přibližuje linux více k widlouzům a mekáčům, system5 je pro staré mechy, kteří nemají rádi novoty a little.owla

systemd mi neumí nastartovat služby na jednom serveru a system5 ano, ale to je moje chyba, že cpu fedoru na desku od supermicra

a tak dále a tak podobně

[mess]

Tak hrozné to není. Na desktop se to hodí výborně. Mám to na NB a funguju bez problémů. A start je rychlejší o cca 10 sekund (20 místo 30), což ostatně byl důvod, proč jsem ten systemd zkoušel a nakonec u něj zůstal.

[l4m4]

Napsal jsem řadu SysV init skriptů a u některých služeb i ekvivalentní systemd unity. Takže si dovolím říci: bullshit.

SysV init skripty jsou hnus velebnosti. Repetitivní a zbytečně komplikované, do toho ještě různé svérázné dodělávky, aby třeba šly ovládat chkconfigem a pod.

Pokud si myslíš, že stačí přečíst kód a je to jasné, tak jsi žádný pořádný init skript ještě neviděl.

Pro staré mechy je BSD init, ti se SysV netknou ani dvoumetrovým klackem.

MS Windows ani OS X nepoužívám, ale mají-li něco jako systemd (řízený a konfigurovaný podobně jako systemd, nejen že to třeba sleduje procesy), tak nám v Linuxu dost ujel vlak.

Zbytek asi PEBKAC...

[Robert Smol]

Zkusim nejake zakladni veci:

Kazdy bash skript co se pousti vytvari, to je zbytecna rezie, Proto mas na initV systemu po nastartovani prvni volne PID treba az 6000, na systemD jses treba na 1200. == rychlejsi startovani (moje fedora bez tweakovani nastartuje na SSD asi tak za 5s).

Dalsi dulezita vlastnost je, ze se snazi necekat a startovat paralelne a to vemi chytre (vytvori socket, takze sluzby necekaji a pak ho jen napoji na nastartovanou sluzbu .. treba dbus).

Systemd take umi dnes jiz spravovat uzivatelske sessions a inteligetne startovat sluzby ktere jsou potreba.

Urcite doporucuji precist duvody proc to vsechno, je to velmi zajimave a i dnes z toho mnoho veci plati: http://0pointer.de/blog/projects/systemd.html

Nejlepsi je, jak lide, aniz by meli paru o tom co mluvi nadavaji na binarni logy. Pritom /dev/kmsg je take binarni :) Navic journal nad systemd je optional, nikomu nic nebrani bezet syslog-ng ci podobne.

[Robert Smol]

Kazdy bash skript co se pousti vytvari novy proces

[tomasgn]

Kazdy bash skript co se pousti vytvari novy proces

no a co, plati se snad za pocet pouzitych procesu?

rychlejsi startovani (moje fedora bez tweakovani nastartuje na SSD asi tak za 5s).

co mate porad s rychlosti startovani? driv si admini pomerovali pindiky podle vetsiho uptimu, dnes pro zmenu podle rychlejsiho bootovani? kolikrat denne ten pocitac (re)startujete? server se startuje obvykle jednou za par tydnu, a na notebooku lze pouzit hibernaci/suspend.

Systemd take umi dnes jiz spravovat uzivatelske sessions a inteligetne startovat sluzby ktere jsou potreba.

softwarove "inteligence" se docela desim. kam se takovy nesmysly zavlecou, jsou z toho jen problemy, a system si dela co sam chce, misto aby delal to, co chci ja.

binarni logy

binarni logy jsou stejne hnuj, jako xml konfiguraky.

[Michal Kubeček]

Kazdy bash skript co se pousti vytvari novy proces, to je zbytecna rezie,

Ta režie není zase až tak velká.

prvni volne PID treba az 6000, na systemD jses treba na 1200. == rychlejsi startovani

Ne, to z toho automaticky neplyne.

moje fedora bez tweakovani nastartuje na SSD asi tak za 5s

Zkoušel jsem měřit rozdíl na OpenSuSE (kde je stále na výběr) a rozdíl nebyl tak zásadní, aby to stálo za horší flexibilitu a debugovatelnost. Zvlášť když se odfiltruje efekt starého triku, že délka bootu se měří do chvíle, kdy se objeví přihlašovací dialog, takže je potřeba ho zobrazit co nejdřív bez ohledu na to, že pak ještě nějakou dobu systém stejně není rozumně použitelný.

Dalsi dulezita vlastnost je, ze se snazi necekat a startovat paralelne a to vemi chytre (vytvori socket, takze sluzby necekaji a pak ho jen napoji na nastartovanou sluzbu .. treba dbus).

Tohle považuji za jednu z podstatných designových chyb systemd.

Systemd take umi dnes jiz spravovat uzivatelske sessions a inteligetne startovat sluzby ktere jsou potreba.

Projev další designové chyby, asi té největší: snaha všechno asimilovat a nedat uživateli na výběr.

Urcite doporucuji precist duvody proc to vsechno, je to velmi zajimave a i dnes z toho mnoho veci plati:

Četl jsem několikrát a nepřesvědčilo mne to ani v nejmenším. Jednotlivé argumenty se pro mne dělí do skupin: (a) umí to i sysvinit, (b) šlo by snadno realizovat i se sysvinit, (c) ve skutečnosti to neumí ani systemd, (d) je to umělá feature pro feature, (e) je to změna k horšímu. Jediné pozitivum je (možná) rychlejší boot, což mi za ty problémy nestojí.

[stativ]

Tak s tímhle komentářem se ztotožňuji, zejména co se týče designových chyb.

[okko]

100% souhlas v každém bodě, dávám +1

[Lol Phirae]

Odpor je marný, budete asimilováni.

[little.owl]

Pro nekoho bug, pro nekoho hezka feature, nic noveho.

[kralyk z abclinuxu]

Systemd take umi dnes jiz spravovat uzivatelske sessions a inteligetne startovat sluzby ktere jsou potreba.

Projev další designové chyby, asi té největší: snaha všechno asimilovat a nedat uživateli na výběr.

Ten myšlenkový proces, kterým si z citované věty vykouzlil tu svou, bude asi skutečná perla.

(a) umí to i sysvinit, (b) šlo by snadno realizovat i se sysvinit

V praxi budou tyhle dvě kategorie v podstatě prázdné, protože SysVinit neumí skoro nic. Obvykle když někdo řekne "umí to i sysvinit", má tím ve skutečnosti na mysli spíš něco jako "Umí to i sysvinit+udev+consolekit+xinted+hromada_podivných_skriptů+případně_další_nástroje", s tím, že celý ten balík okolo sysvinit (díky kterýmu sysvinit vůbec nějak funguje) se instaluje a spravuje opravdu suprově.

[Michal Kubeček]

Samozřejmě že jsem v tomto kontextu výrazem "sysvinit" myslel celý systém initu a na něj navázaných startovacích skriptů. Myslel jsem, že není nutné to celé vypisovat, bohužel jsem se asi mýlil. :-(

[mich]

Dalsi dulezita vlastnost je, ze se snazi necekat a startovat paralelne a to vemi chytre (vytvori socket, takze sluzby necekaji a pak ho jen napoji na nastartovanou sluzbu .. treba dbus).

Tohle považuji za jednu z podstatných designových chyb systemd.

Můžete napsat proč to považujete za chybu?

[stativ]

Spustím SSH, odjedu 900km daleko a když se pokusím přihlásit, zjistím, že SSH se nespustilo a ani nejde spustit?

[mich]

To bych řekl, že pletete dohromady dvě vlastnosti systemd - paralelní start a spouštění služeb on demand. Problém v návrhu té druhé je mi jasný - sám jste ho zmínil. Já jsem se ale ptal na chybu v návrhu té první.

[stativ]

Omlouvám se, špatně jsem si přečetl otázku a myslel jsem, že se ptáte na spouštění on-demand. Sypu si popel na hlavu.

[little.owl]

Pokud spustite prikazy:

systemctl enable my_service.service
systemctl start my_service.service

sluzba my_service je nastartovana po bootu nebo on-demand, podle toho co prijde drive. Navic, pokud vam z nejakeho duvodu sluzba chcipne, systemd je schopen ji restartovat a pokud navic podporuje interface sd_notify() je situace vyrazne lepsi nez uz SysV.

[mess]

Jde o to, že start on demand ti nikdo nenutí. Můžeš si to SSH nechat spustit i "klasicky", tzn, že normálně poběží démon i když na něj nebude žádný požadavek.

[Lol Phirae]

Jde o to, že start on demand ti nikdo nenutí.

Sorry, ale tyhle kydy typu "nikdo ti to nenutí" už nebere nikdo vážně.

[little.owl]

Chcete tvrdit ze v systemd je nemozne spustit sluzbu ihned po startu bez on-demand aktivace?

[mess]

Ano. Aspoň tak se to chová u mě.

[mess]

Hm, tak to dopadá, když člověk spěchá s reakcí a přehlídne jedno "ne-". Samozřejmě, že službu bez on-demand aktivace spustil lze.

[David Jaša]

GOTO #236

[Michal Kubeček]

Za prvé to přispívá k již zmíněnému podvádění "aby se přihlašovací obrazovka zobrazila co nejrychleji". Osobně budu daleko raději, když se přihlašovací obrazovka zobrazí o něco později, ale systém bude v tu chvíli plně nabootovaný a nebude mne poté zdržovat spouštění dalších služeb "až když jsou potřeba".

Za druhé nemám vůbec důvěru ve spolehlivost a robustnost takového řešení. Ono se totiž docela dobře může stát, že bude-li se démon (nebo dokonce sada démonů) spouštět "až když je potřeba", tak než se stihne spustit, nainicializovat a odpovědět na požadavek, protistrana mezitím vytimeoutuje.

Další technické problémy pak mohou souviset s tím, jaký socket se to vlastně vytváří a jak takové "napojení" vlastně vypadá, ale to bych se musel do vnitřností systemd ponořit hlouběji, než by mi bylo milé.

[David Jaša]

Za druhé nemám vůbec důvěru ve spolehlivost a robustnost takového řešení. Ono se totiž docela dobře může stát, že bude-li se démon (nebo dokonce sada démonů) spouštět "až když je potřeba", tak než se stihne spustit, nainicializovat a odpovědět na požadavek, protistrana mezitím vytimeoutuje.

Další technické problémy pak mohou souviset s tím, jaký socket se to vlastně vytváří a jak takové "napojení" vlastně vypadá, ale to bych se musel do vnitřností systemd ponořit hlouběji, než by mi bylo milé.

Přesně to samé se dá napsat i o (x)inetd. Tudíž odpověď je stejná - přes (x)inetd/systemd-on-demand-aktivaci spouštět jen ty démony, u kterých je to vhodné. Tedy tohle bych neměl za zlé systemd, který _nabízí_ fíčuru, nýbrž pisatelům .service souborů, kteří dotyčnou fíčuru užívají v nevhodných případech.

[Ivan]

Joo ten paralelismus je vyborna vec. Kdyz mam na serveru 250 SAN disku (LUNu) a kazdy vidim pres 4 cesty, tak se vsechny udev scripty spusti paralelne a server bootuje pres hodinu. Archaicky AIX nebo HP-UX se sekvencnim BSD initem to same zvladne za 5 minut. Vsechny tyhle chujoviny vymysli lidi, ktey nikdo nebyli odpovedny za zadny produkcni servery. Fakt nechapu proc by se mely veci urceni pro desktop prenaset i na servery. Sekvencni bootovani je dobra vec, kdyz potrebujete zjistit kdy se co stalo a v jakym poradi.

BSD (ale i SystemV) init je vice nez dostacujici pro vsechny situace se kteryma jsem se doted setkal. Kdyz bych potreboval opravdu sofistikovany zpusob spousteni sluzeb, tak si nainstaluju VCS od Veritasu.

[okko]

Je to tak. A na desktop se zase cpou věci, které se hodí na mobil. Rozhodují lidé, kteří nemají rozhled a nadhled, zato mají vize.

[lyon]

A proto se desim toho, co se stane, az se to s RHELem 7 dostane do produkcniho prostredi (viz http://rhel7.net/news/98-rhel-7-roadmap ).

[mess]

Co se stane? Nic se nestane. Akorát budou admini místo nadávání na init nadávat na systemd. Počkat, oni už na něj vlastně nadávají, takže se nezmění vlastně vůbec nic. Žádný konec světa nebude.

[Radek Hladik]

No například já na init nenadávám, ale na systemd jo (i tady několikrát v různých diskuzích). Musím doznat, že ve Fedoře 17 už je systemd vcelku pěkně použitelný a na rozdíl od Fedor 15,16 jsem si opět troufl dát Fedoru 17 na produkční server.

Nebudu tu ale nadávat, to teď a tady nemá smysl. Jen bych chtěl upozornit na důležitou vlastnost té paralelizace. To, že vám naskočí login neznamená, že se systém rozjel. To, že se systém rozjel (čti rozjely se všechny služby) vám systemd nedá nijak vědět.

[okko]

Měl bych dotaz na zdejší advokáty systemd, kteří už přelouskali tu kvalitní dokumentaci k systemd: je možné nějak donutit systemd, aby startoval služby postupně a ne paralelně?

[mess]

No, dokumentaci jsem nestudoval, ale pokud těm službám patřičně upravíš závislosti, tak by měly startovat postupně.

[little.owl]

To, že vám naskočí login neznamená, že se systém rozjel. To, že se systém rozjel (čti rozjely se všechny služby) vám systemd nedá nijak vědět.

Jak neda vedet? Status sluzeb muzete zjistit pres systemctl. Ohledne "rozjeti sluzeb" - to neni jen o paralelnim startu, sluzeby jsou aktivovany az kdyz jsou potreba (on demand), to znamena ze treba i nikdy.

[Radek Hladik]

To, že se musím někam podívat nepovažuju za to, že dá vědět. A ohledně toho, že se služby rozjíždí až když jsou potřeba, to mně děsí pořád. Na desktopu to vzal čert, ale na serveru mám rád, když vím, že všecko nastartovalo a ne, že až to někdo bude potřebovat, tak to nenastartuje...

[little.owl]

[Install]
WantedBy=multi-user.target

[okko]

Za prvé - systemctl status někdy tvrdí, že služba běží i když to není pravda

Za druhé - služby NEJSOU aktivovány tehdy, kdy je potřeba, ale tehdy, kdy si tvůrci distribuce myslejí, že je potřeba a často jsou aktivovány v důsledku nesmyslného galimatyáše všelikých závislostí. Pak se admin diví, že mu zničeho nic něco poslouchá na portech, kde nic nemá běžet a podobně. Systemd je v současné podobě hrozba pro bezpečnost a jestli to Red Hat nasadí do serverových distribucí, tak půjde pod kytky.

[David Jaša]

služby NEJSOU aktivovány tehdy, kdy je potřeba, ale tehdy, kdy si tvůrci distribuce myslejí, že je potřeba

a) co že z toho je problém systemd?

b) co ti brání si napsat vlastní .service soubor, kde nevhodné defaultní hodnoty přepíšeš?

c) co ti brání v protlačení těch lepších .service souborů do upstreamu nebo alespoň do distribuce?

Jako bez trochy aktivity se to do použitelného stavu nikdy nedostane...

[trekker.dk]

Jako bez trochy aktivity se to do použitelného stavu nikdy nedostane...

1. máme použitelný stav
2. vymyslíme nepoužitelnou hovadinu a všem ji vnutíme
3. nadáváme lidem, že musí být aktivní, abychom se dostali do použitelného stavu
4. goto 1

[David Jaša]

Kdyby všechny předřečníkem míněné služby byly startovány v sysvinit prostředí čistě přes xinetd a d-bus aktivaci, taky bys sváděl blbost balíčkářů a pisatelů defaultních konfiguráků na tvůrce xinetd a dbus?

Jako systemd má praktických problémů víc než dost, ale za tohle opravdu nemůže. :P

[trekker.dk]

Kdyby v prdeli byly ryby...

Mě je úplně jedno, co by bylo, kdyby. Pro mě je podstatné, že co předtím fungovalo, teď nefunguje. A lidem se pak nadává, že to místo stížnosti neopravují.

[kralyk z abclinuxu]

Pro mě je podstatné, že co předtím fungovalo, teď nefunguje.

V tomto vlákně je řeč o konfiguraci. Pokud byly konfiguráky špatný i "předtím", nemohlo to dobře fungovat ani "předtím". Pokud byly konfiguráky "předtím" dobrý, nevidím důvod, proč by se nemohli dostat na stejně dobrou úroveň i teď.

[little.owl]

Tm jde hlavne o defaultni konfiguraci, ktere logicky nebude nikdy vyhovovat vsem a vzdy bude dosti situaci, kdy jsou proste "spatne". Jadro pudla je v moznosti si system nastavit tak aby co nejvice vyhovoval mojim potrebam.

[trekker.dk]

Nebyly špatné předtím, ale jsou špatné teď. Ty možná nevidíš důvod, proč by se nemohly dostat na dobrou úroveň, normální lidi nevidí důvod, proč je vůbec rozbíjet.

[little.owl]

ale jsou špatné teď.

Nechcete radsi misto planych tvrzeni konecne konkrekne uvest, co je podle vas ted spatne?

[trekker.dk]

Copak, prohlížeč neumí zobrazit víc než jeden diskuzní příspěvek na stránku?

[little.owl]

Muzete mi sem hodit link, ktery popisuje co predtim fungovalo a nyni se systemd nikoliv?

[little.owl]

Jako bez trochy aktivity se to do použitelného stavu nikdy nedostane...

Ono to je jiz velmi dobre pouzitelne a zminene vyhrady spise prameni z neznalosti a z toho, ze nekomu nemusi vyhovovat defaultni konfigurace, coz tu bude vzdy.

[little.owl]

tak si nainstaluju VCS od Veritasu.

A nebo systemd. Jsem rad ze mam OSS reseni.

[nyan]

Kazdy bash skript co se pousti vytvari, to je zbytecna rezie, Proto mas na initV systemu po nastartovani prvni volne PID treba az 6000.

6000 ? Na jakem distru ? Na mem rhel 6 maji Xka PID ~1600, xfce-session kolem 1700...

rychlejsi startovani (moje fedora bez tweakovani nastartuje na SSD asi tak za 5s).

Muj rhel6 (tedy bez systemd) nastartuje za mozna 30 sekund, a subjektivne velkou cast z toho dela zadavani hesel pro LUKS a pro login do desktopu. Uprimne receno 30 sekund je pro me osobne hranice, za kterou mi to zacina byt vysoce u pr...kenny vohrady, jestli je to o 5s min nebo vic - ty hesla stejne zadavat musim.

Systemd take umi dnes jiz spravovat uzivatelske sessions a inteligetne startovat sluzby ktere jsou potreba.

Pry taky umi spoustu dalsich veci. Ale evidentne nikomu nevadi ze prvni proces bude mit 20M RSS a *tuny* kodu, protoze software prece chyby nemiva, haha.

[Ivan]

Pry taky umi spoustu dalsich veci. Ale evidentne nikomu nevadi ze prvni proces bude mit 20M RSS a *tuny* kodu, protoze software prece chyby nemiva, haha.

Nevim jsem je to se systemd, ale upstart na ubuntu se klidne necha odswapovat. Ten init NEMA uzamceny svuj adresni prostor v RAM - WTF? Takze kdyz omylem spustite fork bombu (make -j), tak se neprihlasite ani na konzoli. Driv mi vadilo, ze root nema staticky linkovany shell. Dynamicky linkovany init to je trochu moc i na me. Process cislo "1" neni zadny deamon, je to specialni process a Linuxovy kernel s nim jedna v mnoha ohledech jinak nez s ostatnimi procesy.

[Rovano]

Já sem to kedysi zkoušel a nakonec jsem se přihlásil, ale než jsme něco udělal, tak OOM to vyřešil

[little.owl]

Slo by to resit pres cgroups a nejake memory limits?

[Ivan]

Urcite by to slo - teda nejsem si uplne jistej, jestli cgroup uz delaji to co slibuji. Bohuzel nezijeme v idealnim svete a ani Linux neni uplne idealni. Ja ocenuju, kdyz SW zvlada ruzne podivne situace, zatimco nekoho zajimaji nove vlastnosti. U kazdeho noveho systemu vam hned naservirujou, co svechno novyho to umi. Pokud ale chcete zjistit o co prijdete, tak na to musite vynalozit spoustu prace. Zrovna u initu bych ocenil, aby byl jednoduchy, prehledny a "cisty". Idealni SW, ktery funguje jen v idealnim svete je naprd.

[little.owl]

Ja systemd vnimam jako posuv dobrym smerem a rozhodne mi prijde pro vetsinu standardnich use casu cistci nez init+script+tuna_dalsich_toolu.

jestli cgroup uz delaji to co slibuji.

Zde bych byl vetsi optimista. V systemd kazda sluzba ci session ma svou vlastni cgroup. Nemel jsem to rad, ale pomalu na to menim nazor, jen se to naucit vyuzit.

[trekker.dk]

Zde bych byl vetsi optimista. V systemd kazda sluzba ci session ma svou vlastni cgroup.

Tohle je pěkná blbost. Já jsem správce toho stroje, tak to mám být já, kdo rozhodne, co má být v které cgroup a jestli vůbec. A ne aby se mi do toho sral nějakej přechytračelej udělátor.

[little.owl]

A ne aby se mi do toho sral nějakej přechytračelej udělátor.

Tak ho nepouzivejte. Prinese vam to praci navic, ale u minoritnich reseni to tak byva.

[kralyk z abclinuxu]

Tohle je pěkná blbost. Já jsem správce toho stroje, tak to mám být já, kdo rozhodne, co má být v které cgroup a jestli vůbec. A ne aby se mi do toho sral nějakej přechytračelej udělátor.

Však se to taky dá zkonfigurovat (afaik).

[little.owl]

Tak da. Ale bylo by lepsi slyset jiny argument nez typu "ja chci", ktery nikdo jiny neni povinen brat na vedomi.