Jaderné noviny – 16. 1. 2014: Lennart Poettering o kdbusu

3. 2. 2014 | Luboš Doležel | Jaderné noviny | 3909×

Aktuální vývojová verze jádra: 3.13-rc8. Citáty týdne: Mark Rutland, Andrew Morton. Shrnutí vlákna: linuxové jádro a PostgreSQL. Změny v grafických ovladačích Intel v 3.14. Příchod kdbusu: Světlé a stinné stránky D-Busu; Vzhůru do jádra.

Obsah

• Aktuální vývojová verze jádra: 3.13-rc8
• Citáty týdne: Mark Rutland, Andrew Morton
• Shrnutí vlákna: linuxové jádro a PostgreSQL
• Změny v grafických ovladačích Intel v 3.14
• Příchod kdbusu
  • Světlé a stinné stránky D-Busu
  • Vzhůru do jádra

Aktuální vývojová verze jádra: 3.13-rc8

Aktuální vývojová verze jádra je 3.13-rc8 vydaná Linusem dne 12. ledna. Nejděsivější věcí na tomto vydání je to, jak pomalé mám připojení, takže patch se stále ještě nehrává, ale každou chvíli už by to mělo být. Nebo možná za půl hodiny. To je fuk. Vydání konečné verze 3.13 se dá očekávat po Linusově návratu z potápění.

Stabilní aktualizace: verze 3.12.8, 3.10.27 a 3.4.77 vyšly 14. ledna. Ještě předtím, 9. ledna, vyšly verze 3.12.7 a 3.10.26.

Citáty týdne: Mark Rutland, Andrew Morton

Pojďme zkontrolovat elektrokardiogram...

           _             _          _        _        _
__________/ \   ________/ \   _____/ \   ___/ \   ___/ \   __
             \_/           \_/        \_/      \_/      \_/

Na těchto vazbách nenacházím žádné nedostatky.

-- Mark Rutland ukazuje, jak se revidují vazby stromů zařízení [device tree bindings].

Ze svých dlouholetých zkušeností vím, že pokud navrhnu alternativní implementaci, tak příznivci počáteční implementace stráví mnoho času předváděním, proč můj návrh nebude fungovat, ale sami hledání alternativ nevěnují ani chvilku.

-- Andrew Morton

Shrnutí vlákna: linuxové jádro a PostgreSQL

Na mailing listu PostgreSQL se odehrává rozsáhlá debata o tom, jak dobře spolu fungují PostgreSQL a linuxové jádro. Mel Gorman zaslal detailní přehled o tom, co doposud bylo probráno; je to zajímavé čtení pro každého, koho zajímá výkon databází na Linuxu. Josh Berkus tvrdí, že většina lidí používá Postgres na 2.6.19, a proto nemusejí lidé tušit o vylepšeních v novějších jádrech. Je až znepokojivé, kolik se toho v jádře mohlo za tu dobu odehrát. Vede to i k otázce, jaký podíl na trhu moderní distribuce dodávající Postgres mají. Bylo by dobré zjistit více o tom, proč starší jádra mezi instalacemi Postgresu převládají.

Změny v grafických ovladačích Intel v 3.14

Daniel Vetter popisuje práci na ovladači Intel i915 připravenou pro jádro 3.14. Jednou z posledních novinek v 3.14 je označení podpory UMS za zastaralou. Tento kód podporujeme už několik let, ale teď začal překážet vylepšování kódu pro načítání a vypínání. Z dlouhodobého hlediska to tedy musí pryč. Prozatím je v jádře volba pro jeho zapnutí.

Příchod kdbusu

Lennart Poettering, oděný do trička s nápisem „Open Source Tea Party“, věnoval svou přednášku na linux.conf.au tématu, na kterém on a několik dalších lidí strávili většinu minulého roku: reimplementace D-Busu v jádře. Výsledek – pokud tedy projde kolečkem revidování – podle Lennarta konečně Linux vybaví pořádným nativním mechanismem pro IPC.

Světlé a stinné stránky D-Busu

Na rozdíl od většiny jader neměl Linux nikdy dobře navržený mechanismus pro IPC. Windows a OS X jej mají; dokonce i Android, postavený na Linuxu, jej má v podobě subsystému „binder“. Linux má ale jen primitiva – sokety, FIFO a sdílenou paměť – která nebyla nikdy sestavena do rozumného API na aplikační úrovni. Kdbus je snahou o takové sestavení a současně snahou o zavedení něčeho, co je alespoň tak dobré jako mechanismy k nalezení na jiných systémech.

Linux má D-Bus, který je podle Lennarta mocným mechanismem pro IPC; jde o něco, co se obvyklé normě v této oblasti nejvíce přibližuje. Lennart si připravil rozsáhlý seznam předností D-Busu. Poskytuje pěkný transakční mechanismus volání metod (umožňující poslat zprávu a dostat odpověď) a nabízí mechanismus pro zasílání „signálů“ (notifikací) zbytku systému. K dispozici jsou mechanismus vyhledávání toho, co dalšího na sběrnici běží, a možnosti introspekce pro zjišťování, jaké služby jsou nabízeny. D-Bus zahrnuje mechanismus pro vynucování bezpečnostních pravidel, možnost spouštět služby při jejich prvním použití, typově bezpečné serializování datových struktur a předávání ověřovacích údajů a popisovačů souborů přes sběrnici. K dispozici jsou obalení pro širokou řadu jazyků, stejně tak i síťová transparence.

Na druhou stranu trpí D-Bus také řadou omezení. Je vhodný pro účely řízení, ale už ne pro cokoliv, kde se mají přenášet větší objemy dat. Proto například D-Bus dobře poslouží, pokud budete chtít říci zvukovému serveru, aby změnil hlasitost, ale raději přes něj neposílejte samotná zvuková data. Problémem je neefektivita implementace D-Busu v uživatelském prostoru; operace volání a návratu (call-return) vyžaduje deset kopií zprávy, čtyři ověření zprávy a čtyři přepnutí kontextu – takhle výkon nezískáte. Navíc jsou možnosti předávání ověřovacích údajů omezené, zprávy nemají časové razítko, D-Bus není k dispozici v ranných fázích bootu, napojení na bezpečnostní frameworky (např. SELinux) musejí probíhat v uživatelském prostoru a okolo aktivace služeb existují race conditions. D-Bus rovněž trpí něčím, co Lennart popisuje jako „barokní kód“, a rozsáhlým užíváním XML.

I tak ale Lennart říká, že D-Bus je „fantastický“ a řeší spoustu skutečných problémů. Deset let jeho používání prokázalo, že jádro jeho návrhu je dobré. Je také dobře zavedený a rozsáhle používaný. Proto je správným řešením nikoliv D-Bus nahradit, ale přinést lepší implementaci.

Vzhůru do jádra

Touto implementací je kdbus, jaderná implementace D-Busu. Tato implementace dokáže přenášet velké objemy dat; dá se rozumně používat pro proudy dat o gigabajtových velikostech. Dovede předávat zprávy bez kopírování, ale i v nejhorším případě jsou zpráva i odpověď přeneseny s pouhými dvěma kopírovacími operacemi, dvěma ověřeními a dvěma přepnutími kontextu. S každou zprávou jsou předávány úplné ověřovací údaje (ID uživatele, ID procesu, popisek SELinuxu, informace o řídící skupině, capabilities a ještě více) a všechny zprávy mají časové razítko. Kdbus je vždy k dispozici (není nutné čekat na spuštění démona D-Bus), linuxové bezpečnostní moduly se na něj mohou přímo připojit, byly vyřešeny různé race conditions a API bylo zjednodušeno.

Kdbus je implementován jako znakové zařízení; procesy, které se chtějí ke sběrnici připojit, otevřou zařízení a pak zavolají mmap() pro namapování paměťového prostoru pro předávání zpráv do svého procesu. Zprávy jsou vytvářeny v této oblasti a pak předávány jádru pro přenos; pro jádro jde o prosté kopírování zprávy z jednoho namapovaného prostoru procesu do prostoru jiného procesu. Zprávy mohou obsahovat časový limit („okna volání metod“), během kterého musí být doručena odpověď. K dispozici je registr jmen podobný tradičnímu registru D-Busu.

Mechanismus „memfd“ umožňuje v kdbusu předávání zpráv bez kopírování. Memfd je oblast paměti, ke které se váže popisovač; podobá se dočasnému souboru namapovanému do paměti, „ale současně se hodně liší“. Memfd je možné „uzamknout“ s tím, že vlastnící proces pak nemůže měnit jeho obsah. Proces, který chce poslat zprávu, ji sestaví v oblasti memfd, uzamkne ji a předá ji kdbusu pro přenos. V závislosti na velikosti zprávy mohou být dané stránky namapovány do adresního prostoru cílového procesu, aby nedocházelo ke kopírování dat. Ale hranice, aby se to nevyplatilo, je docela vysoko; Lennart řekl, že prosté kopírování se vyplatí u všeho, co je menší než přibližně 512 KB. Pod touto velikostí režie spojená s mapováním do paměti vyruší výhody toho, že se data nekopírují.

Memfd je možné dle libovůle opětovně používat. Proces, který potřebuje opakovaně přehrát stejný zvuk, může v memfd jednou uzamknout data a zaslat je zvukovému serveru, kdykoliv to bude potřeba. Podle Lennarta memfd funguje hodně podobně jako subsystém „ashmem“ na Androidu.

Mechanismus pro vysílání signálů byl přepracován tak, aby pro výběr příjemců používal Bloom filtry. Bloom filtry používají hashe pro rychlé vyřazení mnoha kandidátů na příjem, díky čemuž je vysílání signálů relativně efektivní.

K dispozici je proxy server v uživatelském prostoru, který může být používán starším kódem, jenž nebyl přepsán na nové API, takže na systému s kdbusem by vše mělo fungovat bez jakýchkoliv změn v kódu.

Kdy se tohoto kódu dočkáme? Byl ohlášen na mailing listu D-Busu a najdete jej v příslušných repozitářích. Nejvýznamnější věcí, která teď schází, je mechanismus bezpečnostních pravidel. Lennart řekl, že všechno vám bude fungovat, pokud vám nevadí, že to celé bude „děsivě nezabezpečené“. V plánu je kód začlenit do jádra někdy v roce 2014. Věří tomu, že to vyjde; sebevědomí mu dodává to, že do procesu byl zapojen Greg Kroah-Hartman. Lennart ale upozornil, že dva předchozí pokusy o přidání D-Busu do jádra selhaly, takže je to bez záruk.

Více o návrhu kdbusu se dozvíte v souboru kdbus.txt v repozitáři pro jadernou stranu projektu.

       

Komentáře

[erino72]

ten Lennart je nejaky vsemocny, ked sa snazi vsetko v linuxe re-implementovat

[pavel]

Lennart Elop Poettering?

[coques]

Lenny nás spasí všetkých!

[Foo Bar]

A četl jste i samotný obsah sdělení nebo Vám pro vytvoření názoru stačí vidět jeho jméno?

[little.owl]

Nejedna se o reimplemantaci, nybrz novou implementaci.

[D.A.Tiger]

Nemyslím, ze by to byla zas tak scestná myšlenka.

Nějak trpíme na to, že když se nám (obecně linuxářům - na technologiích v Linuxu) něco nezdá, tak to neopravíme, a rovnou to zahodíme a vytvoříme něco nového. S nadějí, že to bude i lepší, ale mnohdy dojde k tomu, že to "nové" řešení je jednak prostě jiné - takže se s ním nejdříve musíme naučit zacházet a jednak s sebou nese nové problémy. Takže pár let na to přijde vystřízlivění a už se začíná přemýšlet čím "novým" to nahradit... A tak je to pořád dokola.

Např. pro mě to nese tu nepříjemnost, že jakmile použiji nějakou technologii třetí strany, brzy na to se ozvou nespokojenci a už jsou tu tendence vytvořit to celé od základů jinak (a to včetně API) což pro mě může znamenat zvykat si na nové rozhraní a fungovaní systému ( v lepším případě), nebo rovnou překopat klidně i celý vlastní projekt. Řekněte sami - koho to má pořád bavit?

Upřímně souhlasím s Lennartem. Sice opravdu teď nevím jak upravit pajšl DBus tak aby byl jako celek efektivnější a bylo možno s jeho pomocí posílat větší objemy dat, ale když je to překážkou považuji za mnohem rozumnější to zkusit nejprve napravit, než budeme vymýšlet zas nějakou novou IPC ...

[Stanislav Brabec]

Upřímně souhlasím s Lennartem. Sice opravdu teď nevím jak upravit pajšl DBus tak aby byl jako celek efektivnější a bylo možno s jeho pomocí posílat větší objemy dat, ale když je to překážkou považuji za mnohem rozumnější to zkusit nejprve napravit, než budeme vymýšlet zas nějakou novou IPC ...

Jediná cesta, jak udělat efektivnější DBus, je přesunout ho do kernelu. Přepnutí kontextu se jinak vyhnout nedá, a kopírování jen za cenu velké režie. Přece je, uživatelský prostor byl úmyslně navržen tak, aby od sebe aplikace maximálně izoloval.

[pavlix]

Otázkou je, kde bereš jistotu, že reálná úzká hrdla D-Busu jsou přepínání kontextu. Z toho, co jsem slyšel od lidí jako je Thomas Woerner jsou hlavní výkonnostní problémy úplně jinde.

[Bedňa]

Z toho, co jsem slyšel od lidí jako je Thomas Woerner jsou hlavní výkonnostní problémy úplně jinde.

Tak nás nenapínaj :)

[little.owl]

Neco najdete tady. Velky problem je serializace, mnozstvi kopirovani, mallocu ci operaci nad stringy. Context switche a podobne veci zacnou hrat roli, az kdyz tohle preskocite.

Vylepseni stareho Dbus-u je stejne jen side effect zamysleneho cile kdbusu .

[pavlix]

Ten si stěžoval tuším na vytvoření samotných objektů uvnitř procesu.

[Bedňa]

Potom by to s dbus nemuselo byť také zlé, ale Lennart tvrdí niečo iné. Teda nikdy ma ani nenapadlo že by sa mal dbus používať na prenášanie veľkých dátových blokov a myslím si že autorov dbus tiež nie.

[pavlix]

Lennart toho nakecá.

[kavol]

Potom by to s dbus nemuselo byť také zlé, ale Lennart tvrdí niečo iné.

již okomentoval pavlix, nicméně nedá mi nevyjádřit podiv nad tím, že si stále někdo není ochoten připustit, že Lennartovi nelze věřit ani nos mezi očima ...

[Bedňa]

Každému je jasné, že keby RedHat umrel, zomrie aj systemd a ďalšie megalomanské projekty, to že čo je jednoduché je dobré proste platí, dá sa to aj matematicky dokázať stavajú sa podľa toho raketoplány.

Ja na týchto vizionárov seru, len je škoda že nás dobehli aj v Linuxe, hoci som pred tým od Widiel utekal. No nič dbus bude žiť ďalej, OpenRC vďaka Gentoistom určite pár rokov ešte vydrží, tak to až tak zle nevidím, ale sere ma to :)

[little.owl]

Každému je jasné, že keby RedHat umrel, zomrie aj systemd a ďalšie megalomanské projekty

Psano pravdepodobne ze systemu, ktery ma v zakladech "nejmegalomanstejsi" SW projekt lidske historie. Systemd, mereno standardnimi metrikami, s ohledem na planovane pouziti, neni nijak velky projekt. Bez podpory RH by se jeho vyvoj vyrazne zpomalil, ale nezastavil; urcite by zivoril mene nez OpenRC.

[Bedňa]

Systemd je ako rakovina čo všetko pohlcuje, v ceste mu stojí už len tebou spomínaný kernel.

[D.A.Tiger]

Tohle mi neda:

Je zajimave, cist tu spoustu nadsenych ohlasu kdyz je najaka novinka, nejlepe nahrada za stary zavedeny projekt v navrhu a potom po jejim nasazeni - s odstupem casu, pomalu pribivajici nadavani.

Jsem zvedav, jak dlouho bude trvat, nez se zacne zase nadavat na Wayland (me osobne znervoznujici uz ted), jakmile se zavede naostro do vetsiny dister....

[Michal Kubeček]

Rozhodně nemám pocit, že by bylo tak moc lidí, kteří dříve psali na systemd nadšené ohlasy a teď na něj nadávají. IMHO většina těch, kdo na něj nadávají teď, na něj buď nadávali od začátku nebo ho ze začátku ignorovali, protože naivně věřili, že bude nasazen pouze jako jedna z alternativ, takže si budou moci vybrat něco jiného.

[kavol]

no, zajímavější než ta skupina nadávajících jsou spíše ti nadšení přikyvovači, že se zas přesunou na rozbourávání něčeho jiného

(a ano, Waylandu se také hrozím ... buď mi to někdo špatně vysvětlil, anebo to bude pro mé typické využití počítače pohroma :-/)

[pavlix]

a ano, Waylandu se také hrozím ... buď mi to někdo špatně vysvětlil, anebo to bude pro mé typické využití počítače pohroma :-/

Já bych řekl, že je to od obojího kus.

[little.owl]

Doufam, ze mi nikdo neodpare, ze tady hujerim konzistentne uz alespon tri roky!

Ale ztratil jsem spojence; plati kdyz mate rad burty, nelezte do tovarny na burty.

[D.A.Tiger]

Rozhodně nemám pocit, že by bylo tak moc lidí, kteří dříve psali na systemd nadšené ohlasy a teď na něj nadávají.

Ono, nejde jen o systemd, tech projektu bylo co ja pamatuji mraky : dcop, corba x dbus; udev x hal x udisks; XFree x Xorg x Wayland, Mir; atd, atd...

Byl jsem vzdycky rad, ze Linuxovy system je zivy a dynamicky, ale ceho je moc, toho je prilis. Tech nekompatibilnich zmen ve svatem tazeni za "nove, lepe fungujici" veci na systemove urovni je moc a prilis rychle. Clovek se o neco snazi, stravi nad tim mraky casu aby mu ve vysledku zbyly oci pro plac, kdyz nekdo zas zacne do sveta vyrvavat ze neco nefunguje jak ocekava... ne snad proto, ze by to treba nemusela byt pravda, ale proto, ze se hned v ruku v ruce s tim obevi spoustu nadsencu, kteri zacnou vyrvavat, ze se to ma zahodit a udelat to jinak.

Dynamika Linuxu je mozna fajn, ale co se posledni dobou deje me zacina spis unavovat.... A to jsem jeste nenasel odvahu se zeptat Jeorena, jestli premysli co bude delat s Fox toolkitem az zacne na linuxove platforme kralovat Wayland (jakoze me to docela trapi)....

[little.owl]

To je jsou dusledky urcite svobody, ktere je ve FOSS vice nez v jinych oblastech a je to dobre.

Byl jsem vzdycky rad, ze Linuxovy system je zivy a dynamicky, ale ceho je moc, toho je prilis.

Zmeny jsou soucasti zivota a cela evoluce a vyvoj temer vseho spise pripomina hledani slepych ulicek. Tohle se netyka jen Linuxu a IT, ale i jinych oboru. Pokud se prestane ucit nove veci, je jen otazkou casu kdy dane oblasti prestanete rozumet se vsemi dopady.

[kavol]

Pokud se prestane ucit nove veci, je jen otazkou casu kdy dane oblasti prestanete rozumet se vsemi dopady.

já bych se strašně rád učil nové věci, jenže na to jaksi nezbývá kapacita, když se musím neustále aktualizovat, že tenhle tejden nám už nestačí hranatý kolo, co se vynalezlo minulej tejden, ale musíme používat bramboroid, a to už jsem slyšel zvěsti, že někomu se bramboroid zdá moc složitej, tak začal od nuly vyvíjet šišoid, a dokonce snad už přesvědčil management, že se ten šišoid po víkendu nasadí ... :-p

[little.owl]

S tim mam problem take, rekl bych ze kazdy - a to muze byt trochu utecha, jenze tak to bylo, je a bude.

Generace meho otce, ktera mela podobne technicke sklony, se casto venovala elektronice, zacinala jako kluci na elekronkach, pak tranzistory, integrovane obvody, diskretni digitalni obvody a nakonec mikroprocesory a presun teziste do SW, veci se stavaly slozitejsi a slozitejsi, s tim ze nektere predchozi pracne ziskane znalosti se stavaly bezcenne a museli se porad ucit. S kazdou zmenou jich cast odpadla a sli delat neco jineho, a nakonec je zasahly zmeny v 89, kdy jim treba neprezila firma ci obor, kde prozili vetsinu produktivniho veku. Vek po padesatce, a pak to bylo casto o tom az se deti osamostatni a doklepat to do duchodu. V UK to nebylo jine, dynamika byla vetsi nez v izolovanem Ceskoslovensku.

My dopadneme podobne, to je jistota.

Jak se s tim poprat, nevim, hledam.

Veci jako Wayland ci systemd jsou jen nicotne zmeny, takze si uzivejme nase flajmy, i kdyz se neshodnem, nebot to minimalne svedci, ze jsme alespon stale trochu v obraze.

Jdete na systemd Fedora Day? Budou tam asi oba vasi oblibenci a kdyz jim nedate do drzky, muzete reportovat, co se tam delo. .

[Heron]

Generace meho otce, ktera mela podobne technicke sklony, se casto venovala elektronice

Trochu off topic:

Občas relaxuju u videí, kde lidé opravdují 70 let staré rádia a o něco málo mladší televize. U těch přístrojů se někteří snaží zachovat maximum původních součástek, vymění jen nezbytné minimum. A víte co? Na konci oprav to rádio zapojí do zásuvky, kde je po celou dobu stejné napětí / frekvence, připojí k anténě a naladí nějakou dnešní stanici na stejném pásmu, jako před 70 lety a se stejnou modulací. A to rádio hraje, hrálo by kontinuálně už 70let.

Mě tohle přijde fantastické. V našich oborech se 2 roky stará věc musí nutně vyměnit / upgradovat, někteří lidé čtou standardy jen proto, aby věděli jak je nejlépe porušit. Protokoly mají pro jistotu záměrně nekompatibilní implementace a přitom existují obory (a není jich málo), kde desítky let kompatibility jsou standardem.

[sigma]

To je pravda, ale řekl bych, že nesmíme přehlížet neskutečný rozdíl ve složitosti, komplexnosti, těch věcí.

Ono i v IT, v "naších oborech", se v některých případech drží desítky let zpětné kompatibility. Ať už je to třeba i386/amd64 a podpora všech možných historických režimů běhu CPU, nebo třeba v extrémním případě platforma IBM Mainframe. Když se na to podívám, tak taková kompatibilita je držená buď za velmi vysokou cenu a/nebo je třeba často kritizovaná jako zbytečná.

Na druhou stranu takové TCP/IPv4 je tu už pěkně dlouho, a dost možná bude navždy paralelně s IPv6. A je to asi tak úroveň, na které může s dnešní dynamikou vývoje být nějaká trvalá kompatibilita držená.

U napětí/frekvence toho moc nového vymyslet nejde, ani by to nemělo žádný smysl. A zrovna nad těmi desítky let stejnými modulacemi se smráká, u TV už je po nich, a rozhlas to čeká taky - je jen otázka za jak dlouho.

[Heron]

U napětí/frekvence toho moc nového vymyslet nejde, ani by to nemělo žádný smysl.

U dálkových tras se přechází z AC na DC a mnohem vyšší napětí. AC např. v letadlech je na 400Hz, protože čím vyšší frekvence, tím menší cívky a jádra traf (tam jde o hmotnost). 50/60Hz je takový kompromis daný spíše otáčkami alternátorů než požadavky na přenos.

A zrovna nad těmi desítky let stejnými modulacemi se smráká, u TV už je po nich, a rozhlas to čeká taky - je jen otázka za jak dlouho.

Pro komerční využití jistě, ale jako fallback tady AM a FM bude navždy. Vysílač se dá postavit s jedním transistorem (a elektronku si reálně lze vyrobit doma) a na příjem AM stačí jeden vhodný krystal.

[kavol]

Generace meho otce, ...

jenže elektronka => tranzistor => IO je skutečný vývoj

tady bych použil Heronův příklad, kdyby se třeba napětí v síti měnilo co chvíli, tak chudák elektronik akorát furt předělává ty svoje elektronkové designy a na nějaké tranzistory nemá čas

Jak se s tim poprat, nevim, hledam.

stát se rentiérem; ti méně schopní (jako já) aspoň být připraveni změnit obor

... což mi připomíná, stále hledáme místo, kde se usadit, pořád nikdo neví o nějakým pěkným mlejnu nebo usedlosti, ev. i jen pozemku? (pozn. pěkným - myslím lokalitou, stav by se hodil naopak nepěkný, protože deset mega na dřevo za luxusní baráček jaksi vysázet nemůžeme)

Veci jako Wayland ci systemd jsou jen nicotne zmeny,

nejde o konkrétní projekty, ty jsou pouze indikátorem nezdravého stavu celého oboru

Jdete na systemd Fedora Day? Budou tam asi oba vasi oblibenci a kdyz jim nedate do drzky, muzete reportovat, co se tam delo. .

v zájmu zachování zaměstnání se takovýmto příležitostem vyhýbám

[Bedňa]

Generace meho otce, ...

jenže elektronka => tranzistor => IO je skutečný vývoj

tady bych použil Heronův příklad, kdyby se třeba napětí v síti měnilo co chvíli, tak chudák elektronik akorát furt předělává ty svoje elektronkové designy a na nějaké tranzistory nemá čas

Jj s týmto prirovnaním sa nedá než súhlasiť.

[little.owl]

jenže elektronka => tranzistor => IO je skutečný vývoj

O tom nepochybuji. Pointa byla v tom, ze lide se museli vzdy ucit, a ty zmeny probihaly vzdy na pochodu.

Za poslednich sest let, kazdy muj projekt zacinal na zelene louce, s novymi vecmi, s kompletne prekopanou architekturou, od jednojadra, pres FPGA, k hetegennimu monstru s osmi jadry a GPU, od DDR po DDR3, od dvou napajecich napeti k peti, k petivrstvym plosnakum, od analogovych kamer k digitalnim streamum, AVB, OpenGL, OpenCL, peti OS, kupou algoritmu, slepych ulicek a zmatenych specifikaci. Prezil jsem a naucil se s tim zit, a spise jsem si to i uzival.

Co mozna dlouhodobe nepreziji je koupe nasi male firmy molochem se 170k zamestnanci, jejich managementem, a zavadenim jejich procesu, nesmyslnymi poradami, vecmi jako Lotus Notes, IBM Rhapsody, MKS Integrity, kdy veci co trvaly tri hodiny, trvaji ted tri tydny, a kdy lide v top level managementu teprve po roce zjistili ze koupili neco v Anglii a je treba odpovedet na otazku, co bude dal.

stát se rentiérem; ti méně schopní (jako já) aspoň být připraveni změnit obor

Na tom je podobne vetsina z nas, co musi chodit do prace aby zaplatila ucty, a pro nez je prace posledni zoufaly pokus jak prijit k penezum.

Budem past ovce, ja ve Skotsku a vy do Beskyd nemate take daleko .

nějakým pěkným mlejnu

Mlejn => asi voda pobliz => pryc.

nejde o konkrétní projekty, ty jsou pouze indikátorem nezdravého stavu celého oboru

Nemyslim, narozdil od treba usr move mi davaji smysl.

v zájmu zachování zaměstnání se takovýmto příležitostem vyhýbám

Ani Rezza vas neuhlida?

[kavol]

Co mozna dlouhodobe nepreziji je koupe nasi male firmy molochem se 170k zamestnanci, jejich managementem, a zavadenim jejich procesu, nesmyslnymi poradami, vecmi jako Lotus Notes, IBM Rhapsody, MKS Integrity, kdy veci co trvaly tri hodiny, trvaji ted tri tydny, a kdy lide v top level managementu teprve po roce zjistili ze koupili neco v Anglii a je treba odpovedet na otazku, co bude dal.

LOL

Budem past ovce, ja ve Skotsku a vy do Beskyd nemate take daleko .

no, až na ty Beskydy to mám vpodstatě v plánu

Mlejn => asi voda pobliz => pryc.

proč?

nejde o konkrétní projekty, ty jsou pouze indikátorem nezdravého stavu celého oboru

Nemyslim, narozdil od treba usr move mi davaji smysl.

nejde jen o to, jestli to vůbec dává smysl, ale třeba i (nebo spíš hlavně?) o provedení

Ani Rezza vas neuhlida?

copak je to snad nějakej bodyguard?

[little.owl]

Mlejn => asi voda pobliz => pryc.

proč?

Mozna zaplavova oblast, jak jsem zazil, romanticke je to do doby dokud neprijde povoden.

Ani Rezza vas neuhlida?

copak je to snad nějakej bodyguard?

A to neni jedna z jeho funkci zajistit, abyste se tam neprali?

[kavol]

Mozna zaplavova oblast, jak jsem zazil, romanticke je to do doby dokud neprijde povoden.

no, vono se tak nějak historicky počítalo, že ta voda se občas zvedá, a podle toho věci zařídily

to jenom v poslední době lidi jaksi neví, co je to příroda, a pak se jenom diví, když je to vyšplouchne ...

A to neni jedna z jeho funkci zajistit, abyste se tam neprali?

tak o tom nic nevim

[Heron]

Pokud se prestane ucit nove veci

Jsou ty věci skutečně nové? Čas od času se objeví zcela "nový revoluční přístup" o kterém se při troše znalostí dá s klidem prohlásit, že to už se vědělo nebo umělo před 40 lety. Jen, bohužel, ti tvůrci to neví. Už hodně dlouho jsem se nenaučil nic skutečně nového a to se "nové" věci učím kontinuálně.

[little.owl]

Jsou ty věci skutečně nové?

Jak pro koho.

[kavol]

Jsou ty věci skutečně nové?

hm, což mi připomíná, že jsem se docela pobavil (vlastně ještě se bavím) hype kolem cloudu, což je za mou relativně krátkou kariéru v IT již druhá reinkarnace principu, na kterém IBM budovalo datacentra již v šedesátých letech minulého století

Už hodně dlouho jsem se nenaučil nic skutečně nového

no, já jsem teď nucen do nosql databází, což je tuším relativně nový koncept ... aspoň zatím jsem o tom nenašel nic ve stylu "to navrhoval už von Neumann"

[Heron]

no, já jsem teď nucen do nosql databází

Tak to záleží, co se tím konrétně myslí. Protože například databáze typy key-value (což je kde co, akorát se tomu přidá formát json nebo co dneska letí), je v podstatě to, co se jmenuje hash tabulka na disku, což byla jedna z prvních forem hierarchického ukládání dat. Takže třeba berkeley db, která na rozdíl od některých nosql je acid transakční a další starší produkty.

Osobně nosql považuji za stejný hype a buzzword jako třeba ten cloud. Vytváří se dojem, že sql je cosi zastaralého, nosql je něco brutálně nového, přičem, samozřejmně, sql jazyk byl vyvinut mnohem později, než db. Některé produkty na jazyk sql přešli až časem z nějakého původního api.

[kavol]

tady je problém, že název je poněkud nešťasný (jo, hype ...) a nevystihuje podstatu, neb ve skutečnosti vůbec nejde o jazyk

ano, na key-value není nic nového, ale to jaksi není to jediné - tady bych si opět vypomohl již použitým příměrem, též neříkáme, že integrovaný obvod je o ničom, neb to jsou vlastně jenom pospojované tranzistory ...

[Bedňa]

Ani si nepamätám kedy som naposledy mal s Linuxom niekde problém. Teda občas s niektorými šmejďárskymi grafikami v notebookoch, občas netradičnejšia Wifi, ale to sú problémy čo sa napríklad na Widlách nedajú vôbec riešiť.

Ja som proste roky spokojný užívateľ. Do Widel a softu okolo som pred rokmi napchal kopu prachov a že jak ma srali, teraz sa to blíži ku mne zas. Jebu na to nechcem systemd, nechcu kdbus a ani žiadne blbosti od vizionárov, našťastie je to posledná záchrana v LFS a to hádam nezničia

Mne Linux funguje, tak mi ho nechajte a chodte všetci do ....

[little.owl]

Ani si nepamätám kedy som naposledy mal s Linuxom niekde problém.

Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pamet .

nechcu kdbus

A jste mi alespon vy racionalne schopen vysvetlit, proc by message based IPC nemohlo byt soucasti kernelu? Nechcu, nechcu .... jini chcu.

posledná záchrana v LFS a to hádam nezničia

Nejnovejsi LFS.
Klasicky init + kopa shell skryptu, ci treba init se zavislostmi a deklarativni syntaxi jsou legitimni koncepce, jak inicializaci systemu resit. Kazdy ma pravo se svobodne rozhodnout co bude pouzivat a podporovat, o tom je FOSS, a to vcetne Red Hat. Vetsina byla uz recena, tedy jen dve veci: (a) nepocitejte s tim, ze zastanci jine koncepce budou vyvijet tu vasi, nebudou, to musite vy sami, jste konkurenti; (b) svet okolo init se bude menit, a bude na nej klast vetsi a jine pozadavky, kazda koncepce initu se bude muset prizpusobit, obvinovat ostatni, ze jim to rozbiji a myslet si ze vystacim ze zmrazenym kodem je cesta do marginality.

[pavlix]

Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pamet .

To říká člověk, který stejným způsobem mluví o systemd, nedej bože Gnome 3. Jsou případy kdy si opravdu nejde nerýpnout.

[David Jaša]

Nějak v sovičkových příspěvcích nevidím implikaci, že by systemd či gnomí peklo byly bez problémů. Spíš bych to viděl tak, že problémy "starého světa" člověk tolik nevnímá, protože workaroundy na ně má už pod kůží.

[little.owl]

Nějak v sovičkových příspěvcích nevidím implikaci, že by systemd či gnomí peklo byly bez problémů.

Rozhodne nejsou, vzdycky je to trade-off. Znam vyvojovy cyklus SW od sameho pocatku na zelene louce do stabilniho produktu, i radikalni refaktoraci starsiho systemu v kratkem case a tusim ve ktere fazi ma ekvivalentni pozici Fedora a kde RHEL a tak vim co cekat.

Ted cekam co prinese Fedora.next a kam se to posune.

[Josef Kufner]

Ani si nepamätám kedy som naposledy mal s Linuxom niekde problém.

Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pamet .

To záleží na tom, jak se o svoje stroje staráš. Pokud je máš odladěné a používáš je jako pracovní nástroj, tak to funguje a problémy prakticky neexistují. Pokud to máš jako hračku, tak je jasné, že to bude každou chvíli rozdrbané.

[little.owl]

To záleží na tom, jak se o svoje stroje staráš.

Ne. Zalezi predevsim jake distro pouzivate.

Pokud je máš odladěné a používáš je jako pracovní nástroj, tak to funguje a problémy prakticky neexistují.

Odladit to musi predevsim distribuce. Na veci, kde potrebuji stabilitu, bych nepouzil nic jineho nez Debian Stable/CentOS/RHEL/SUSE.

Systemd budu hodnotit predevsim podle CentOS 7.

[Josef Kufner]

"jake distro pouzivate" ∈ "jak se o svoje stroje staráš".

[little.owl]

Plno adminu nema na vyber a pokud jejich SW/distro je zabugovana sracka, tak jim starani moc nepomuze.

[kavol]

(a) nepocitejte s tim, ze zastanci jine koncepce budou vyvijet tu vasi, nebudou, to musite vy sami, jste konkurenti;

to nepočítáme ... ale nemohli bychom alespoň počítat s tím, že "zastánci jiné koncepce" se nebudou aktivně snažit tu naši rozbít? - my jim to taky neděláme ...

[little.owl]

Ja souhlasim s tim, ze lide kolem systemd/Gnome se chovaji obcas bezohledne a nesleduji jeden z nutnych prvku FOSS, kterym je urcita uroven spoluprace. Nicmene to nemeni nic na faktu, ze koncepci a smer systemd mam rad a povaziji ji za spravnou.

[Bedňa]

Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pamet .

Tak Pavlix by napr. mohol napísať čo by sa dalo ohľadne sieťovania v Linuxe vylepšiť a niečo pre to už aj spravil, ale pravda je taká, že to aj teraz funguje. Windows, alebo MAC je na tom lepšie? Nezahodím predsa Kernel a nezačnem ho písať nanovo, pokiaľ je tam nejaká chyba.

A jste mi alespon vy racionalne schopen vysvetlit, proc by message based IPC nemohlo byt soucasti kernelu? Nechcu, nechcu .... jini chcu.

Pretože dbus funguje, teda aspoň na to čo sa dnes používa. To sa naozaj na Win a Mac presúvajú cez IPC veľké dátové bloky? Teda aby to nebola oneman fjučúra, ktorú aj tak nikto nebude používať akurát sa nám tam nasáčkuje ďalšie množstvo kódu ktoré časom nikto nebude udržiavať.

Klasicky init + kopa shell skryptu, ci treba init se zavislostmi a deklarativni syntaxi jsou legitimni koncepce, jak inicializaci systemu resit. Kazdy ma pravo se svobodne rozhodnout co bude pouzivat a podporovat, o tom je FOSS, a to vcetne Red Hat. Vetsina byla uz recena, tedy jen dve veci: (a) nepocitejte s tim, ze zastanci jine koncepce budou vyvijet tu vasi, nebudou, to musite vy sami, jste konkurenti; (b) svet okolo init se bude menit, a bude na nej klast vetsi a jine pozadavky, kazda koncepce initu se bude muset prizpusobit, obvinovat ostatni, ze jim to rozbiji a myslet si ze vystacim ze zmrazenym kodem je cesta do marginality.

Naozaj to je so všetkým tak zlé, že to treba zahodiť? Čo to tak potichu prekopať zvnútra nech užívateľ/administrátor/programátor/účtovníčka ani nevie že sa niečo zmenilo. To by ale nikto nevedel o malom uhučam chlapcovi čo chce spasiť svet, kurwa ten ma ale sere, som myslel že sa udržím, ale to sa nedá.

RedHat vyhadzuje svoje prachy na hrozné blbosti čo rozbíjajú Linux enviroment a vyzerá, že sa to nedá zastaviť, to už sa tam nenájde nikto, kto by povedal poďme robiť veci poctivo nenasierajme dlhoročných užívateľov, nemenme zažité veci, nejebme sa zbytočne do hierarchie súborov ... Roky nebolo problém staré zdrojáky kompilovať, prípadne ich trochu priohnúť, dnes? Dnes je to peklo, lebo túto politiku nedorobiť jedno, rozdrbať druhé ste prebrali od vizionárov tohoto sveta všetci. Ďakujeme a kašlite na starých užívateľov aj naďalej. Beriem ťa ako šikovného človeka na svojom mieste, ale toto je môj pohľad na tento pokrok. Prepáč, ale nedalo sa to zastaviť.

[Michal Kubeček]

To sa naozaj na Win a Mac presúvajú cez IPC veľké dátové bloky?

Ta propustnost pro velké datové toky byl jen jeden z důvodů (a osobně mám pocit, že zrovna tohle není moc dobrý důvod). Při normálním (příčetném) použití je AFAIK problém spíš v latencích a škálovatelnosti při velkém počtu zúčastněných klientů.

[Bedňa]

To zas Pavlix tvrdil, že Thomas Woerner tvrdil, že to nieje pravda :)

[pavlix]

Na to bych byl opatrný. Ale minimálně Thomas identifikoval užší místo na jiné úrovni stacku. Otázkou je, jak se k D-Busu chovají jiní a zda se jim daří úzká místa natolik eliminovat, že se jim skutečně context switche projeví.

[little.owl]

Pretože dbus funguje, teda aspoň na to čo sa dnes používa.

Bedna, kdbus neni nahrada dbus, dbus ho muze pouzit. Kdbus je novy prvek. V soucasnosti se snazime presunout nektere aplikace, ktere nevyzaduji beh na certifikovanem/standardizovanem systemu na Linux, ze systemu kde messaging je zakladnim stavebnim prvkem IPC a proto potrebujem neco jako kdbus s nizkou latenci, prijatelnou propustnosti a scalingem, pokud mozno sdileny v ramci kernelu, jinak to budeme reimplementovat porad kazdy znovu a znovu, a jeste blbe.

Naozaj to je so všetkým tak zlé, že to treba zahodiť?

To neni ani tolik o zahazovani, jako ze Red Hat a dalsi se zamerili na jinou koncepci, ktera ma nesporne vyhody. Ja chapu, ze pro jine koncepce je to neprijemna situace, nemaji zdroje udrzovat vsechna alternativni reseni a citi se zahnani do kouta. Budou se s tim muset sami poprat, prostor a poptavka pro alternativni reseni tu je.

[Bedňa]

Ja viem že vývoj je potrebný, aj to že si každý platí za to čo jemu vyhovuje je jasné, ale nemente to zvonku, nedrátujte napevno do projektov súčasti ktoré by mali byť vždy voliteľnou súčasťou (V README by mala byť výstraha). Takto za rok, možno dva si tu budeme písať tak kdbus nebol až tak dobrý ako sa myslelo, máme nový výborný nápad (a že môže byť fakt výborný) a užívateľom ktorím to autori softvéru stihli napevno zadrátovať do závislostí sa týmto ospravedlňujeme. Teraz to vyzerá ako scifi, ale ono sa to v poslednej dobe deje a nemyslím len RH, ale obecne Linux enviroment. Myslím si že to netvrdím len ja ale dosť developerov by mi dalo za pravdu.

[little.owl]

IPC zalozene na predavani zprav jsou tady od 60.let, principu bych se nebal. Jina vec je user API, to se nebude moci menit a tak doufejme, ze to promysleli poradne; implementace se zmeni jeste nekolikrat.

S modularitou souhlasim, ale tam nevidim problem na strane kernelu.

Pokud vim, pouzivate Debian; zkuste si nainstalovat Debian Testing se systemd a pouzivat to par tydnu a trochu si to osahat. Uvidite ze to funguje a nebe nepada, pripadne bugy se resi, a ja jsem si celkem jist ze v budiucim Debian Jessie to budete mit stabilni a spolehlive, at uz bude defaultni init cokoliv.

[Bedňa]

Hlavne aby user API bolo dobre navrhnuté a nemenilo sa niekoľko rokov, ako píšeš sú tu zaužívané veci okolo IPC, tak sa dúfam nechajú inšpirovať a pri ďalšom výbornom nápade sa nebude musieť meniť, hoci kdbus nahradí LPbus. Toto beriem ako základ toho, že sa jedného dňa začnú na Linux obracať aj veľké firmy s env Win.

Modularita je super v každom smere.

Jj som hlavne Debiansta, momentálne mám aj Sabayon na notebooku s systemd, je to len na krátkodobý test, úplne si nejásam, ale chápem že ešte nie som v obraze. Bude nasadený na iný stroj tak možno za pol roka sa budem vedieť podeliť o výsledky.

[xyz]

posledná záchrana v LFS a to hádam nezničia

Nejnovejsi LFS.

Alebo tiež verzia bez systemd tak stabilná ako aj vývojová.

[xyz]

A doplním, že udev bol práve nahradený eudev. Bruce Dubbs najprv 4.3. v lfs-dev popisuje komplikácie s udev:

"I've been working on udev and have got it to build with the systemd-210 source. The problem is that it is getting more and more intertwined with the rest of systemd requiring things that don't seem to be applicable. ... My question is whether we need to try either eudev or mdev. Does anyone have any experience with eudev or mdev?"

A následne 7.3. zaradil eudev namiesto udev:

"I've replaced systemd wuth eudev in LFS. Please have a look and test. Feedback welcomed."

Takže LFS je stále ešte poslednou záchranou, ako písal vyššie Bedňa. A dúfam, že to tak aj vydrzí.

[D.A.Tiger]

Nemam problem s Linuxem jako takovym. Mam problem s dopady mysleni komunity kolem neho. A to je trochu rozdil....

[little.owl]

To je horsi nez Otesanek! Maminko, bojim, bojim.

[kavol]

Psano pravdepodobne ze systemu, ktery ma v zakladech "nejmegalomanstejsi" SW projekt lidske historie.

eh, a to myslíš který?

napadá mě linux jako kernel, ale na tom není nic megalomanského, to je hobby projekt

no a pak samozřejmě GNU, ale na tom opět nevidím nic megalomanského, prostě sada nástrojů v operačním systému, takových je dvanáct do tuctu a šedesát do kopy ...

Systemd, mereno standardnimi metrikami, s ohledem na planovane pouziti, neni nijak velky projekt.

"velký" a "megalomanský" nejsou synonyma

Bez podpory RH by se jeho vyvoj vyrazne zpomalil, ale nezastavil; urcite by zivoril mene nez OpenRC.

v této fázi by se už nezastavil, ale kdyby tam ta podpora nebyla historicky vůbec, tak po tom dneska neštěkne pes

[little.owl]

to je hobby projekt

Jedna vec je minulost, druha soucasnost. Vyvoj Linuxu je dnes tazen velkymi firmami a placenymi vyvojari a k hobby projektu to ma sakra daleko.

"velký" a "megalomanský" nejsou synonyma

Pak mi neni jasne, co tomu vycita.

v této fázi by se už nezastavil, ale kdyby tam ta podpora nebyla historicky vůbec, tak po tom dneska neštěkne pes

A kde berete tu jistotu? Proc tedy vznikaly veci jako initng, launchd, upstart, Solaris SMF a FreeBSD zacina investovat energii do openlaunchd? Mozna by to nebyl systemd, treba neco jineho, ale poptavka po tomto smeru by byla; a opet, umi byt ve vhodny cas na spravnem miste.

[kavol]

to je hobby projekt

Jedna vec je minulost, druha soucasnost. Vyvoj Linuxu je dnes tazen velkymi firmami a placenymi vyvojari a k hobby projektu to ma sakra daleko.

řekl bych, že k tomuto je též relevantní poznámka o rozdílu mezi velkým a megalomanským ...

myslím si, že Linuse sice těší, kdo všechno a kde všude Linux používá, ale nějak jsem si nevšiml, že by ho někomu cpal, a prakticky veškerá jeho práce pro rozšíření spočívá v přidávání podpory pro další platformy a snaze vyhovět, co by kdo v jádře potřeboval

naopak systemd je tvůrci aktivně prosazován, jejich cílem je vytlačit vše ostatní, a na podporu ostatních platforem zvysoka serou, naopak často ji záměrně komplikují

(pozn. v prvém případě mluvím spíše o hardwarové platformě, v druhé spíše o software, i když důsledky Lennartovy náklonosti k SSD v neprospěch rotačních disků nebo nedejbože jiných technologií taky známe, že)

"velký" a "megalomanský" nejsou synonyma

Pak mi neni jasne, co tomu vycita.

řekl bych, že snahu zničit vše ostatní?

A kde berete tu jistotu?

pozorování ...

za prvé, Lennart nejenže není schopen své projekty dotahovat do konce, ale ani u nich nevydží

za druhé, za tím, že systemd aspoň nějak funguje, stojí obrovský[*] tým lidí, který se opravdu nedal dohromady tak, že by si všichni řekli "nemáme co dělat, pojďme hackovat systemd"

[*] relativně, na projekt této velikosti

Proc tedy vznikaly veci jako initng, launchd, upstart, Solaris SMF a FreeBSD zacina investovat energii do openlaunchd? Mozna by to nebyl systemd, treba neco jineho, ale poptavka po tomto smeru by byla; a opet, umi byt ve vhodny cas na spravnem miste.

tady ovšem nebyla položena otázka, kde by byly (jsou) initng, launchd, upstart, Solaris SMF a openlaunchd, nýbrž kde by byl systemd

[little.owl]

snaze vyhovět, co by kdo v jádře potřeboval

Uvidime jak vyhovi potrebam kdbus.

řekl bych, že snahu zničit vše ostatní?

Je dosti pravdepodobne, ze pokud bych mel vase informace a moznost videt veci z vaseho pohledu, urcite by se muj nazor posunul, ale takhle mi to prijde trochu paranoidni.

za prvé, Lennart nejenže není schopen své projekty dotahovat do konce, ale ani u nich nevydží

Ano. Nekteri lide jsou vhodnejsi pro implementaci noveho projektu a jini pro dlouhodoby support a stabilizaci noveho kodu. Tech druhych je potreba casto vice a jsou mene videt. Lennart by uz mel pomalu jit nebo omezit aktivitu, systemd by to IMHO prospelo.

za druhé, za tím, že systemd aspoň nějak funguje, stojí obrovský[*] tým lidí,

Jsem si toho vedom a proto verim, ze se to dotahne do konce a je na kazdem posoudit sve investice.

nýbrž kde by byl systemd

Klicova je poptavka, byl tu prostor a on ho obsadil, zbytek je spekulace.

[kavol]

řekl bych, že snahu zničit vše ostatní?

Je dosti pravdepodobne, ze pokud bych mel vase informace a moznost videt veci z vaseho pohledu, urcite by se muj nazor posunul, ale takhle mi to prijde trochu paranoidni.

nevycházím z ničeho tajného, ostatně spousta informací a odkazů padla už i tady

jako příklad likvidace konkurence mohu uvést například fedoří featuru, pardon, "change", která si honosně říká "no default syslog" a ve skutečnosti znamená "journald as default syslog"

před systemd bylo možno používat (jedno z) rsyslog, syslog-ng, syslogd či cokoli, co admin preferoval, zatímco nyní je vynuceno použití journald

a že by systemd prostě nešel naprogramovat, resp. bylo to neúměrně, co neúměrně, troufnu si na silnější tvrzení - jakkoli složitější než aby na journald nezávisel natvrdo, to mi prostě nenamluvíš

Ano. Nekteri lide jsou vhodnejsi pro implementaci noveho projektu

to ale nemluvíš o Lennartovi, že?

nebo máš paměť kratší ještě než Bedňa a nepamatuješ si ukázky zásadních designových problémů, které jsem tu dával, jednu z nich docela nedávno právě s tím čekáním na journald?

za druhé, za tím, že systemd aspoň nějak funguje, stojí obrovský[*] tým lidí,

Jsem si toho vedom a proto verim, ze se to dotahne do konce a je na kazdem posoudit sve investice.

jsi-li si si toho vědom, pak nerozumím, proč polemizuješ s výchozím tvrzením a ptáš se, kde beru jistotu, že bez RH (resp. obdobného sponzora) by po systemd neštěk pes?

nýbrž kde by byl systemd

Klicova je poptavka, byl tu prostor a on ho obsadil, zbytek je spekulace.

viz výše, nebo jinak, poptávku po jabkách těžko uspokojí shnilý rajčata

[little.owl]

nevycházím z ničeho tajného, ostatně spousta informací a odkazů padla už i tady

Naznaku bylo dost, ale opravdu si na tom nechci formovat definitivni nazor. I s takovymi lidmi je nutne v zivote pracovat a vyjit, casto mohou byt i nadrizeni.

jako příklad likvidace konkurence mohu uvést například fedoří featuru, pardon, "change", která si honosně říká "no default syslog" a ve skutečnosti znamená "journald as default syslog"

To je spise vnitrni politika Fedory. Forwardovani jiz nechodi?

jakkoli složitější než aby na journald nezávisel natvrdo, to mi prostě nenamluvíš

Tak urcite by to slo udelat. Spekuluji, ze chce mit pod kontrolou agregacni bod pres ktery tecou logovana data.

designových problémů, které jsem tu dával, jednu z nich docela nedávno právě s tím čekáním na journald?

To mi prijde jako problem pramenici z nedostatku zkusenosti a prvotnich nedomyslenosti, kterych je ve vyvoji plno. Staci srovnat zamyslenou architekturu na zacatku projektu a na konci. Pokud delate neco poprve, nektere veci predelavate v nekolika iteracich. Ve finalnim produktu by to byt nemelo a rika to kam Fedora patri. Tyhle bugy mne vadi podstatne mene nez ty, ktere ukazuji, ze jediny test byl test kompilatorem.

[kavol]

Naznaku bylo dost, ale opravdu si na tom nechci formovat definitivni nazor.

ok, no já jen že to o těch informacích mi přišlo trošinku nefér

jako příklad likvidace konkurence mohu uvést například fedoří featuru, pardon, "change", která si honosně říká "no default syslog" a ve skutečnosti znamená "journald as default syslog"

To je spise vnitrni politika Fedory.

za prvé, přistoupíme-li na toto tvrzení, pak se naskýtá otázka, proč je ta politika právě taková - to se jako členům FESCO zjevil Bůh a řekl "Mojžíšovi jsem dal desatero, vám dávám příkaz vyhodit z Fedory klasický syslog"?

za druhé, tvrzení, že je to problém, ehm politika, Fedory je podle mého s prominutím kec - Fedora akorát nyní jako první udělala explicitně další krok, nicméně každé jiné distro, co používá aktuální[*] systemd, na tom bude stejně ... nebo ty bys, coby člověk s rozhodovací mocí v distru, chtěl, aby uživatelům běžely dva démony, co dělají víceméně to samé, notabene když druhý je závislý na prvním? proč potom tedy ten druhý nevyhodit?

[*] v F19 jsem zmiňovaný problém s pomalostí journald ještě mohl obejít systemctl mask journald; takto zkonfigurovaný systém mi ovšem už po updatu na F20 nenabootoval

Forwardovani jiz nechodi?

zatím asi ano, ale viz výše

jakkoli složitější než aby na journald nezávisel natvrdo, to mi prostě nenamluvíš

Tak urcite by to slo udelat. Spekuluji, ze chce mit pod kontrolou agregacni bod pres ktery tecou logovana data.

ha ha, až příliš laciné

(ok, tak se na to podívejme třeba z hlediska filozofie a morálky: chtít může, ale proč by probůh měl mít nárok si to uzurpovat, proč by totéž nemohl chtít někdo jiný?)

designových problémů, které jsem tu dával, jednu z nich docela nedávno právě s tím čekáním na journald?

To mi prijde jako problem pramenici z nedostatku zkusenosti a prvotnich nedomyslenosti, kterych je ve vyvoji plno.

"ve vývoji" jsou silná slova, řekl bych ... proč je tedy k vývoji připuštěn člověk bez zkušeností a který věci nedomýšlí?

(tedy "připuštěn" ... ať si každý dělá co chce, otázkou spíše je, proč to ostatní přijímají s nadšením - přijde mi to skoro jako kdyby když já si na vandru u vohně falešně kvákám, tak se přihnal někdo s nahrávací aparaturou a dělal z toho druhýho Gotta ..)

Staci srovnat zamyslenou architekturu na zacatku projektu a na konci. Pokud delate neco poprve, nektere veci predelavate v nekolika iteracich.

to je další kus problému - Lennart nepředělává, Lennart je prostě dokonalý, a pokud má někdo s nějakým kódem problém, tak to není bug ale featura a chyba na straně toho, kdo ten problém má

(konkrétní příklad, abych neplácal do větru? - tak třeba iniciální přístup, že množina akcí podporovaných službami, kterou jsme (= my, veličenstvo Lennart) na začátku nadefinovali, musí stačit pro každou službu) (ostatně, tuším, že se i tady před nějakým časem řešil problém se službami, které vlastně nejsou služby, nemají žádného démona, to byl taky boj)

Tyhle bugy mne vadi podstatne mene nez ty, ktere ukazuji, ze jediny test byl test kompilatorem.

hm, tady se zase rozcházíme ... ty bugy, že neprojde A / B když B = 0 se dají spravit, ale ty krpy v designu tak leda obejít, a to ještě kdoví jestli ...

[little.owl]

za prvé, přistoupíme-li na toto tvrzení, pak se naskýtá otázka, proč je ta politika právě taková - to se jako členům FESCO zjevil Bůh a řekl "Mojžíšovi jsem dal desatero, vám dávám příkaz vyhodit z Fedory klasický syslog"?

Ale proslo to u FESCO, ne? A to je vice nez Mojzis!

nebo ty bys, coby člověk s rozhodovací mocí v distru, chtěl, aby uživatelům běžely dva démony, co dělají víceméně to samé, notabene když druhý je závislý na prvním? proč potom tedy ten druhý nevyhodit?

Ano, vyhodit. Kdyz oba delaji +- to same, proc mit ten druhy? Hadam, ze journald bude brzo umet vice nez Rsyslog. Red Hat nema rad Adiscon.

[*] v F19 jsem zmiňovaný problém s pomalostí journald ještě mohl obejít systemctl mask journald; takto zkonfigurovaný systém mi ovšem už po updatu na F20 nenabootoval

Pokud jsem to pochopil v sobotu, log socket a veci kolem jsou zahardkodovane, coz muze byt duvod. Kazdopadne, pokud to rozbije system a nenabootuje, je treba to reportovat jako normalni bug.

... proč je tedy k vývoji připuštěn člověk bez zkušeností a který věci nedomýšlí?

Pokud delate neco noveho, zkusenosti s urcitou oblasti nemate a casto je sbirate na pochodu. Ne vse lze domyslet, casto veci menite na zaklade praktickych testu, prototyping je normalni soucasti vyvoje.

to je další kus problému - Lennart nepředělává, Lennart je prostě dokonalý, a pokud má někdo s nějakým kódem problém, tak to není bug ale featura a chyba na straně toho, kdo ten problém má

Jeho silne neotresitelne pozici nerozumim.

(konkrétní příklad, abych neplácal do větru? - tak třeba iniciální přístup, že množina akcí podporovaných službami, kterou jsme (= my, veličenstvo Lennart) na začátku nadefinovali, musí stačit pro každou službu) (ostatně, tuším, že se i tady před nějakým časem řešil problém se službami, které vlastně nejsou služby, nemají žádného démona, to byl taky boj)

To je problem toho, kdo ho ukoluje, kazdy projekt ma mit ramcovou specifikaci.

hm, tady se zase rozcházíme ... ty bugy, že neprojde A / B když B = 0 se dají spravit, ale ty krpy v designu tak leda obejít, a to ještě kdoví jestli ...

Chyby v designu se daji opravit tak, ze se zmeni design a vcas, drive nez to dostane uzivatel, od urcite faze na to nejsou cas ani zdroje. Tady se snad jedna jen o zmenu ve zpusobu jak se ukladaji data, v podstate optimalizaci. Mysleno to bylo jinak - cim jste v pokrocilejsi fazi projektu, chyby ktere resite jsou zaludnejsi a obtizneji odhalitelne a reprodukovatelne, to je normalni a jsem vuci tomu tolerantni. Trivialni chyby mne vadi.

[kavol]

za prvé, přistoupíme-li na toto tvrzení, pak se naskýtá otázka, proč je ta politika právě taková - to se jako členům FESCO zjevil Bůh a řekl "Mojžíšovi jsem dal desatero, vám dávám příkaz vyhodit z Fedory klasický syslog"?

Ale proslo to u FESCO, ne? A to je vice nez Mojzis!

eh? říkám že neprošlo? - ptám se proč ...

nebo ty bys, coby člověk s rozhodovací mocí v distru, chtěl, aby uživatelům běžely dva démony, co dělají víceméně to samé, notabene když druhý je závislý na prvním? proč potom tedy ten druhý nevyhodit?

Ano, vyhodit.

hm, a co takhle trvat na tom, aby optional byly oba, druhý nemusel záviset na prvním, a uživatel si mohl vybrat?

Kdyz oba delaji +- to same, proc mit ten druhy?

třeba proto, že někomu ten druhý vyhovuje lépe?

Hadam, ze journald bude brzo umet vice nez Rsyslog.

což ale může být důvod proti němu

Red Hat nema rad Adiscon.

no, v souladu s vývojem v posledních letech by bylo spíše jej koupit ...

Pokud jsem to pochopil v sobotu, log socket a veci kolem jsou zahardkodovane, coz muze byt duvod. Kazdopadne, pokud to rozbije system a nenabootuje, je treba to reportovat jako normalni bug.

ne, to není bug, to je featura, že to bez journald nemůže běžet ... o tom se tu snad celou dobu bavíme, ne?

... proč je tedy k vývoji připuštěn člověk bez zkušeností a který věci nedomýšlí?

Pokud delate neco noveho, zkusenosti s urcitou oblasti nemate a casto je sbirate na pochodu.

to není odpověď na mou otázku, to je naopak argument na podporu toho, že jsme se Lennartovu návrhu měli vyhnout velkým obloukem

Ne vse lze domyslet, casto veci menite na zaklade praktickych testu, prototyping je normalni soucasti vyvoje.

to je sice pravda, nicméně toto nelze aplikovat na komplet kód - viz příklad, který tu omílám: fakt nepotřebuju praktické testy k tomu, abych zjistil, že je-li jedním z mých cílů zrychlit boot, není vhodné přidávat bezpodmínečné čekání na věc, která pro boot není důležitá

To je problem toho, kdo ho ukoluje, kazdy projekt ma mit ramcovou specifikaci.

nějak jsem si nevšiml, že by ho někdo úkoloval ... asi nemám dost insider info ale jeví se mi to tak, že si dělá co chce

Chyby v designu se daji opravit tak, ze se zmeni design a vcas, drive nez to dostane uzivatel,

což se právě neděje

Tady se snad jedna jen o zmenu ve zpusobu jak se ukladaji data, v podstate optimalizaci.

asi si nerozumíme ... je-li řeč stále o tom problému s čekáním na journald, tak já za zásadní fuckup považuju to, že se na něj vůbec čeká; to, jak neoptimálně pracuje a jestli mu to trvá deset sekund nebo deset minut je pro mě podružné (i když to také vypovídá o kvalitě návrhu a implementace)

[little.owl]

eh? říkám že neprošlo? - ptám se proč ...

Jak opravdu rozhoduje FESCO je pro me zahada, IRC logy jsou k ******, ale mate u vas nekolik clenu, proc se jich nezeptat?

hm, a co takhle trvat na tom, aby optional byly oba, druhý nemusel záviset na prvním, a uživatel si mohl vybrat?

Je to design decision. Journald je pevnou soucasti architektury, pokud uzivatel chce mit logy i jinde, muze si je forwardovat (F20, chodi to, s prislusnym overheadem a duplikaci dat). Proc je tomu tak, nevim. Ma to sve vyhody i nevyhody.

fakt nepotřebuju praktické testy k tomu, abych zjistil, že je-li jedním z mých cílů zrychlit boot, není vhodné přidávat bezpodmínečné čekání na věc, která pro boot není důležitá

A je to finalni reseni? Pri vyvoji se bezne provozuje system ve stavu, kdy rada veci je implementovana z poloviny, a dodelani nema v dane dobe prioritu. Cekat muze, ale pak at je inicializace journald rychla, neceka se na uloziste, loguje do rychleho memory bufferu a az je uloziste k dispozici, asynchronne se to zapise, cesty jsou.

ne, to není bug, to je featura, že to bez journald nemůže běžet ... o tom se tu snad celou dobu bavíme, ne?

Musi to i tak nabootovat, to je otazka fail-safe reseni a moznosti recovery. Pokud to nenabootuje, je to bug.

to není odpověď na mou otázku, to je naopak argument na podporu toho, že jsme se Lennartovu návrhu měli vyhnout velkým obloukem

Ne, tam je potreba review od dalsich lidi a korekce designu, to je problem one man show.

nějak jsem si nevšiml, že by ho někdo úkoloval ... asi nemám dost insider info ale jeví se mi to tak, že si dělá co chce

No, pokud rozhovaci proces vypada takto:

Ahoj Jime, jak se mas, jak je v Raleigh?
Fajn, Lennart, fajn, umrela mi kocka.
To je mi opravdu lito, Jime.
Jime, chtel bych zrychlit boot Fedory, je to pomale.
Hmmm ... to je. A jak to chces udelat?
Predelam init, to je takova strasne stara vec, a pomala, 20 let na to nikdo nesahl.
20 let?! Lennart, mas zelenou.

pak ano.

[kavol]

eh? říkám že neprošlo? - ptám se proč ...

Jak opravdu rozhoduje FESCO je pro me zahada, IRC logy jsou k ******, ale mate u vas nekolik clenu, proc se jich nezeptat?

no, poslední konzultace s Marcelou mi toho moc neobjasnila, nicméně pointou této otázky nebylo se tu vypovídat z mých starostí na toto téma, ostatně to jsem již dávno učinil, nýbrž zjistit, co tedy vlastně míníš tou "politikou" a proč o tom takhle píšeš ...

Je to design decision. Journald je pevnou soucasti architektury, pokud uzivatel chce mit logy i jinde, muze si je forwardovat (F20, chodi to, s prislusnym overheadem a duplikaci dat). Proc je tomu tak, nevim. Ma to sve vyhody i nevyhody.

tož ... a jaké jsou ty výhody toho, že si nemůžu vybrat logovacího démona?

fakt nepotřebuju praktické testy k tomu, abych zjistil, že je-li jedním z mých cílů zrychlit boot, není vhodné přidávat bezpodmínečné čekání na věc, která pro boot není důležitá

A je to finalni reseni?

no, když budou zákazníci hodně řvát, tak asi ne, každopádně výmluva na to, že je to dočasné(*), je jedna z největších pitomostí, co jsem v posledních dnech četl - to už jsi s tou obhajobou fakt tak v úzkých?

(*) notabene když se tu zároveň mluví o tom, že se ta situace s tímto ještě zhoršila, v F19 to čekání ještě nebylo povinné, journald se dal vypnout, ve F20 už ne, takže ten vývoj toho "prototypu" jde v tomto od desíti k pěti - namísto aby se to, co se v praxi ukáže být problematické, nějak obešlo, tak se z toho udělá nutnost - WTF?

ne, to není bug, to je featura, že to bez journald nemůže běžet ... o tom se tu snad celou dobu bavíme, ne?

Musi to i tak nabootovat, to je otazka fail-safe reseni a moznosti recovery. Pokud to nenabootuje, je to bug.

fajn, bugzilla.redhat.com je ti k dispozici, já už nemám sil se s tou klikou hádat, investoval jsem docela dost energie už jenom do toho, abychom aspoň dosáhli stavu, že na tom systémy nechcípou

to není odpověď na mou otázku, to je naopak argument na podporu toho, že jsme se Lennartovu návrhu měli vyhnout velkým obloukem

Ne, tam je potreba review od dalsich lidi a korekce designu, to je problem one man show.

to se ale neděje

No, pokud rozhovaci proces vypada takto: ...

no, v některých případech to nebude daleko od reality

[little.owl]

no, poslední konzultace s Marcelou mi toho moc neobjasnila, nicméně pointou této otázky nebylo se tu vypovídat z mých starostí na toto téma, ostatně to jsem již dávno učinil, nýbrž zjistit, co tedy vlastně míníš tou "politikou" a proč o tom takhle píšeš ...

Kazda distribuce je zalozena na urcitych idejich, ktere jsou pak formovany do politik, od zpusobu jak je spravovana, po release ci balickovaci kriteria. Jedna vec jsou psane dokumenty, druha vec je prakticka realizace, napriklad v ramci FESCO, ktere by teoreticky nektere zde kritizovane veci mohlo zastavit. Muj dojem, treba podle IRC logu, polovina lidi tam mlci, zrejme maji jasno a neciti potrebu to zduvodnit (nebo uz je rozhodnuto), vrcholem odporu je presunuti do dalsiho release, casto spise jen proto, ze je to tak rozdrbane, ze nic jineho zatim delat nejde; a obcas je treba lidi jako byl Garrett uvest do reality. Tedy, "politikou" myslim tuhle praktickou realizaci.

V realu to bude asi jednodussi: lidi co prosazuji tyto zmeny maji silne kryti, jednaji v souladu s pozadavky vedeni, mozna i podstatne casti vyvojaru a tech par protestujicich zoufalcu jako vy a vam podobni s tim nic nemuzou udelat, a tim se nikoho nechci dotknout.

Pro me je to nepruhledne a kdybych nemel rad Fedoru, nerad rolling distribuce a nepreferoval SELinux, jsem uz u Arch/Gentoo, protoze jim rozumim vice.

tož ... a jaké jsou ty výhody toho, že si nemůžu vybrat logovacího démona?

Tak to neni, vy si muzete vybrat demona, ale nemuzete vyradit journald. Vyhoda? Me se to obhajovat nechce, nebot bych to tak neudelal. Muze to byt napriklad zabezpeceni logu ci efektivnejsi kontrola lograte per logovanou sluzbu; kouknete se do systemd TODO. Asi si tady nadelal do bot, pokud jsou vsecnhy testy co ma v systemd/src/journal, tak by me neprekvapilo, kdyby pri vetsim realnem logovacim loadu zkoncil u narusenych dat; tohle mel napsat clovek se zkusenostmi s datovymi ulozisti a databazemi.

no, když budou zákazníci hodně řvát, tak asi ne, každopádně výmluva na to, že je to dočasné(*), je jedna z největších pitomostí, co jsem v posledních dnech četl - to už jsi s tou obhajobou fakt tak v úzkých?

Vubec ne. Fedora je pro me trochu prototyp, vyvojova verze, o tom ze se pusti veci za ktere by zakaznici Red Hat ukamenovali, nepochybuji. Jak jsem psal, celou tuhle vec budu hodnotit az podle CentOS 7.

to se ale neděje

Viz. moje kritika rozhodovaci procesu. Duvod proc si myslim, ze by Lennart mel uz odejit neni to, ze by byl spatny programator ci SW architekt, ale to ze vedle nej nejsou schopni i jinak technicky zdatni lide ziskat prostor.

[kavol]

Kazda distribuce ...

ok

Pro me je to nepruhledne a kdybych nemel rad Fedoru, nerad rolling distribuce a nepreferoval SELinux, jsem uz u Arch/Gentoo, protoze jim rozumim vice.

Gentoo SELinux umí, pokud nejni vyladěnej, tak můžeš přiložit ruku k dílu a s tím rolling, no, mám dojem, že denně dostávám do Fedory nejmíň dvakrát tolik updatů, co do Gentoo ...

tož ... a jaké jsou ty výhody toho, že si nemůžu vybrat logovacího démona?

Tak to neni, vy si muzete vybrat demona, ale nemuzete vyradit journald.

no, takže si musím vybrat journald => nemůžu si vybrat ...

Vyhoda? Me se to obhajovat nechce, nebot bych to tak neudelal. Muze to byt napriklad zabezpeceni logu ci efektivnejsi kontrola lograte per logovanou sluzbu; kouknete se do systemd TODO.

to by zdůvodňovalo volbu jako default, nikoli nemožnost to vypnout/vyměnit

když už se zmínil ten selinux ... to je taky default, a když si ho někdo vypne, tak Dan zabije koťátko nebo tak něco, ale přesto pořád vypnout jde - jakto, když je to taková užitečná věc, určitě neméně užitečná než journald?

Asi si tady nadelal do bot, pokud jsou vsecnhy testy co ma v systemd/src/journal, tak by me neprekvapilo, kdyby pri vetsim realnem logovacim loadu zkoncil u narusenych dat; tohle mel napsat clovek se zkusenostmi s datovymi ulozisti a databazemi.

mno, na to nepotřebuje ani "větší reálný logovací load", při analýze toho mého oblíbeného problému s čekáním na journald to tam někdo zmiňoval, že ty záznamy potom za určitých okolností nejsou ve správném pořadí (se správnými timestampy)

no, když budou zákazníci hodně řvát, tak asi ne, každopádně výmluva na to, že je to dočasné(*), je jedna z největších pitomostí, co jsem v posledních dnech četl - to už jsi s tou obhajobou fakt tak v úzkých?

Vubec ne. Fedora je pro me trochu prototyp, vyvojova verze, o tom ze se pusti veci za ktere by zakaznici Red Hat ukamenovali, nepochybuji. Jak jsem psal, celou tuhle vec budu hodnotit az podle CentOS 7.

ale já nemluvím o tom, jestli je Fedora vývojářské hřiště nebo ne, já mluvím o tom, že tady (v tom konkrétním případě) vedl vývoj naopak ke zhoršení již tak špatného, namísto aby se to na základě praktických zkušeností řešilo jinak

[little.owl]

Gentoo SELinux umí, pokud nejni vyladěnej, tak můžeš přiložit ruku k dílu a s tím rolling, no, mám dojem, že denně dostávám do Fedory nejmíň dvakrát tolik updatů, co do Gentoo ...

Vedle Fedory testuji ted lehce opet Arch, ke Gentoo se take dostanu. Ano, take bych me zacit neco delat.

zhoršení již tak špatného, namísto aby se to na základě praktických zkušeností řešilo jinak

A ja jsem optimista a verim, ze je to zhorseni docasne, protoze stejne nemate jinou moznost nez to opravit.

[pavlix]

Vedle Fedory testuji ted lehce opet Arch, ke Gentoo se take dostanu. Ano, take bych me zacit neco delat.

Než se k tomu dostaneš, tak tam já možná budu používat Fedora toolchain bez chrootu ;).

[chrono]

Predpokladám, že nebol príliš veľký problém dať tú časť, ktorá je journald zodpovedná za možnosť používať "klasický" syslog priamo do systemd. Problém ale je, že v takom prípade by pravdepodobne takmer nikto nepoužíval journald (a keďže teraz aj tak musí byť spustený, tak je väčšia pravdepodobnosť, že niekto zabudne vypnúť ukladanie binárnych logov, takže budú mať viac používateľov :) )

[Michal Kubeček]

Problém ale je, že v takom prípade by pravdepodobne takmer nikto nepoužíval journald

Proč "problém"?

[kavol]

tomu se říká trefa do černého

[Michal Kubeček]

Už jsem to psal několikrát, ale osobně vidím skutečný problém právě v tom, že jsme se nenápadně dostali do doby manažerských rozhodnutí. Za starých dobrých časů (TM) musel nový projekt, který chtěl nahradit nějaký široce používaný, sám přesvědčit uživatele, že je natolik dobrý, aby jim stálo za to na něj přejít. To nebylo jednoduché a velmi často starý a nový projekt žily roky vedle sebe. Na nové projekty tím byl automaticky vyvíjen tlak, že musí fungovat aspoň tak dobře jako staré, jinak nemají šanci. Spousta jich to nedokázala a zanikly nebo živoří, což je ale jen dobře.

Dnes o takových věcech rozhodují úzké skupinky lidí, takže není až tak důležité, co bude více vyhovovat uživatelům, ale kdo dokáže produkovat PR cílené na tyto lidi. A to Lennart Poettering očividně zvládá perfektně. Nový projekt, který se prosadí tímto způsobem, nemusí být spolehlivý a nemusí být ani aspoň tak funkční jako ten, který chce nahradit. Celé se to pak zaštiťuje nesmyslnými hesly jako "release early, release often", "one tool per task" apod. Pod záštitou takových hesel se dá do distribuce úplně rozbité KDE4 jako default a když se zjistí, že uživatelé si stejně raději vyberou funkční KDE3, v příští verzi se KDE3 vyhodí, přestože KDE4 je pořád rozbité (i když o něco méně). A teď se totéž děje se systemd a jeho odnožemi (journald, logind, zanedlouho networkd). Je mi z toho smutno…

[Heron]

+1

[kavol]

v principu z hloubi celého srdce souhlasím, jen bych poznamenal, že s tím KDE to není úplně šťastný příklad, neb KDE4 nebyl nový projekt nýbrž pokračování projektu stávajícího, distributoři neměli příliš mnoho jiných voleb, jestliže stará verze prakticky přišla o podporu - kdyby v tu chvíli existovalo Trinity, byla by to jiná, v podobné situaci s GNOME3 máme nyní v distru MATE (a uživatelé si raději vyberou XFCE )

[chrono]

Xfce je v podstate tiež takmer mŕtve (zatiaľ ale našťastie všetko viac-menej funguje).

[little.owl]

Uvidime. Portovani do GTK3 by nemel byt velky problem, kvuli Waylandu by se muselo nahradit cele xfwm4, coz je vetsi orisek ale ani to neni nerealne.

[kavol]

Každému je jasné, že keby RedHat umrel, zomrie aj systemd a ďalšie megalomanské projekty, to že čo je jednoduché je dobré proste platí, dá sa to aj matematicky dokázať stavajú sa podľa toho raketoplány.

Ja na týchto vizionárov seru, len je škoda že nás dobehli aj v Linuxe, hoci som pred tým od Widiel utekal. No nič dbus bude žiť ďalej, OpenRC vďaka Gentoistom určite pár rokov ešte vydrží, tak to až tak zle nevidím, ale sere ma to :)

asi jsem po ránu natvrdlej, ale nechápu souvislost s mým komentářem ...?

[Bedňa]

Ani ja

[Michal Kubeček]

Sice opravdu teď nevím jak upravit pajšl DBus tak aby byl jako celek efektivnější a bylo možno s jeho pomocí posílat větší objemy dat

Zrovna tohle je věc, která se mi na tom moc nelíbí. To, že současná implementace, to efektivně neumí, aspoň nutí vývojáře, aby používali D-Bus jako IPC a ne jako univerzální transportní mechanismus. Pokud to kdbus bude zvládat lépe, tochu se bojím, že se začne coby univerzální klacek nesmyslně používat i na věci, které by daleko lépe řešily třeba roury nebo sockety.

[little.owl]

Pokud to kdbus bude zvládat lépe, tochu se bojím, že se začne coby univerzální klacek nesmyslně používat i na věci, které by daleko lépe řešily třeba roury nebo sockety.

To je samozrejme velke riziko, zejmena kdyz to bude/je vice user friendly, a [snad] s mene temnymi zakoutimi.

[Josef Kufner]

A čemu by to vadilo?

Pořád je to zbytečná komplikace, když už tam jeden komunikační mechanismus je. Leda tak předat přes dbus otevřenou rouru, ale musela by to umět už samotná knihovna obalující kdbus, aby to aplikace měly snadné.

Sběrnicový přístup má výhodu v mnohem snažším ladění (lze snadno odposlouchávat již připraveným nástrojem) a implicitně modulárním přístupu (oproti socketu lze snadno přidat druhý server).

[Michal Kubeček]

Třeba tomu, že to bude méně efektivní a bude to fungovat hůře, než kdyby se ty velké datové objemy posílaly způsobem, který je k tomu vhodný. Přirovnal bych to třeba k tomu, že je dnes běžné používat TCP nebo dokonce HTTP i pro účely, pro které je celá síla těch protokolů úplně k ničemu a dalko víc by se hodilo použít třeba UDP. Jenže vývojář je holt líný, tak použije hotovou knihovnu a uživatel se pak strašně diví, jaké mu tam naskáčou latence, sotva se ztratí pár paketů.

A já se prostě obávám, že jakmile vývojáři desktopových aplikací zjistí, že posílání větších objemů dat přes D-Bus už není taková katastrofa jako dřív, budou přes něj za chvíli posílat úplně všechno včetně živých audio a video streamů.

[Josef Kufner]

A pokud by to výkonostně bylo srovnatelné se sockety? Pokud se kdbus udělá dobře, tak by tomu tak klidně mohlo být.

[Michal Kubeček]

To mi nepřipadá moc reálné.

[Heron]

No to mě zajímá, pokud by to bylo srovnatelné se sockety, tak měl by se, nebo by se neměl používat kdbus?

[petr_p]

Jestli přetrpíš, že tvoje úžasná aplikace bude fungovat jen na Linuxu?!

[Michal Vyskočil]

Přečti si něco o AF_BUS, třeba na lwn.net a pak zjistíš, že sockety opravdu nejsou všechno. Nebo Gregovo shrnutí o tehdy budoucím kdbus.

Především tohle:

Our goal (...), is to provide a reliable multicast and point-to-point messaging system for the kernel, that will work quickly and securely.

[Michal Kubeček]

return -EINVALIDCONTEXT;

[chrono]

A pretože to má fungovať bezpečne, tak pre istotu žiadnu bezpečnosť zatiaľ neriešia.

[pavlix]

Nějak trpíme na to, že když se nám (obecně linuxářům - na technologiích v Linuxu) něco nezdá, tak to neopravíme, a rovnou to zahodíme a vytvoříme něco nového.

Otázkou zůstává, proč to děláte :).

[D.A.Tiger]

Jo..., tak nad tim si hlavu lamu uz taky pekne dlouho. Mozna to je pro vyvojare pohodlnejsi, mozna to trochu vychazi z principu open source, a mozna to nekdy je opravdu potreba - ale urcite ne snad u kazdeho druheho systemoveho projektu, u ktereho se najde par nedostatku...

[little.owl]

Kdbus neni nahrada Dbusu, ale muze byt pouzit k jeho vylepseni; Lennart byl jen ve spravny cas na spravnem miste a vyuzil poptavky.

[Michal Vyskočil]

Kdbus neni nahrada Dbusu, ale muze byt pouzit k jeho vylepseni;

A ten, koho to napadlo pojmenovat kdbus je osobně zodpovědný za cca 90% komentářů "D-BUS je odporný, nepoužívám, vypínám, windowsovatění, ..." tady a všude jinde. Jmenovat se to třeba kmmsg2 a netahat do toho D-BUS, většina lidí by to prostě přešla, jako většinu změn v kernelu. Až si říkám, že si LP v těch kontroverzích libuje a dělá to schválně.

[pavlix]

Taky mám ten dojem. Už jen název AF_BUS byl daleko přijatelnější, ale tam se dá pochopit, že ho nechtěli duplikovat. Navíc by se neměli ani tak srovnávat s D-Busem, jako s Netlinkem, který si taky našel své příznivce.

[little.owl]

Rekl bych, ze ten nazev sel mimo nej, termin "kernel dbus" se pouzival v diskuzich uz minimalne tri roky, bylo to spise na GKH.

[tacoberu]

Zní to hodně dobře.

[Tom.š Ze.le.in]

Omlouvám se že zase komentuju jen překlad - ale větě "It begs the question what sort of penetration modern distributions shipping Postgres has." v originále sice úplně nerozumím, ale jsem si z kontextu celkem jistý, že se mluví o market penetration, ne o penetračním testování.

(ne že bych byl tak úchylný a procházel a porovnával celý překlad s originálem, jen když mi něco nedává smysl - a tady to nedávalo. Za tyhle shrnující překlady jsem rád.)

[Luboš Doležel (Doli)]

Přísahal bych, že jsem tam viděl "penetration testing", ale asi jsem si to nějak představoval. Opravím to.

[little.owl]

Doufam, ze to projde do mainstreamu, tahle implementace je o rad lepsi nez AF_BUS a ten ma v praxi slusne vyuziti.

[npp]

Jak muzete hodnotit implementaci, kdyz tam toho jeste hafo chybi ? Jedinej commit od Lennarta je fakt komickej ;)

Jen tak dal, kriplove z RedHeatu kripli Linux a pracujou na metamorfoze na desktopovy shit ala MS Windows. Congratz.

[Sid]

jediny commit???? ste si pozreli posledny stav vsak? existuje aj cosi ako historia ale to vam zrejme unika

[npp]

Tak jsem se probrowsoval historii az k 1.2.13 a dobre, tech commitu je tam asi 20, ale to je radove min nez ostatni jako Kay a Daniel Mack. A nektery jsou opravdu 'marginal'. Tak ze se tu vytahuje Lennartovo jmeno, ale makal na tom nekdo jinej.

[pavlix]

Tak ze se tu vytahuje Lennartovo jmeno, ale makal na tom nekdo jinej.

To už je snad standardem, ne?

[little.owl]

To už je snad standardem, ne?

Musis se vice snazit, a trochu lezt do spravne zadnice, a taky za tebe bude kodovat nekdo jiny a ty sliznes smetanu .

Mame tu Eiffelovu vez ci Karluv most, a jmena tech co si na tom zhuntovali sve zdravi se nedozvime, stejne jako tech co si na systemd uhnalo mysoidni loket.

Jeho jmeno tam neni prislis zamerne, ma to pak vetsi sanci na projiti, spise jsem ocekaval ze tam bude vice GKH, ale on to jen zastituje jak jeji kralovska vysost sbirku na chude. OK, mel posledni slovo v designu, je to na nem.

[little.owl]

Zkuste se kouknout treba sem, drive nez zacnete ze sebe delat pitomce; a btw (a) GKH neni od Red Hat, (b) messaging system ma v sobe zabudovano plno OS, i na hony desktopu vzdalenych.

[npp]

Zlaty Github oproti Google code. Tak tam ma 47, vcetne takovych jak jsem odkazoval. Kay a Mack kolem 500. Plati teda co jsem psal, ze to je projekt predevsim techto lidi a ne Lennarta.

Psal jsem ze Greg je od RH ? Tak mi nevkladej do huby co jsem nepsal. Kay a Lennart kazdopadne jsou.

[little.owl]

Lennart se podilel na designu doslova od sameho pocatku a inicioval ho, v podstate to zacalo minuly rok na GNOME Developer Hackfestu v Bruselu. Kod zacal vznikat v unoru a byl prubezne k dispozici. Rekl bych, ze o tom vite kulovy, ale mate zbytecne silna vyjadreni.

[Sid]

miesto aby ste zobrali spat svoje hlupe vyhlasenie, tak sa nejako snazite to stale obhajit... Omyl (unahlenost) sa moze stat hocikomu ale trvat na svojej blbosti to je uz cosi napoveda.

[little.owl]

A pokud by vas zajimala systemd strana - jako jednoho z uzivatelu kdbus - muzete zacit zde.

[Heron]

Deset let jeho používání ..

To už ho vypínám 10 let jo? Toto letí.

[henkye]

Já ho nevypínám, v .xinitrc mám exec dbus-launch openbox-session protože se to tak dělá ale k čemu to je, netušim Vim akorát o jedný věci, která to používá. Launcher co se přes dbus zeptá, jestli už neběží skype a případně jen obnoví okno.

[pavlix]

Já tam ještě pouštím takové věci jako ssh agenta a policykit ;).

[BFU]

Treba se taky casem zmeni systemd na system32 a nebudes potrebovat nic poustet

[pavlix]

Zrovna systemd momentálně nepoužívám.

[Heron]

protože se to tak dělá

Za ty roky, co vypínám (resp. nezapínám*), jsem se několikrát ptal, k čemu je to dobré. Kromě arogantních odpovědí se mi nikdy nedostalo konkrétního příkladu. A v mé praxi mi nikdy nechyběl a stále nechybí, a proto jsem se na to ptal. Ale tak dík za první konkrétní příklad, obnovení okna Skype je fajn no .

*) Podle mého názoru je správný postup při instalaci je takový, že se vypnou všechny služby a potom se pozapínají pouze a jen ty, které jsou nutně potřeba. Dle přístupu dokonalé není to, kam nelze nic přidat, ale to, odkud nelze nic odebrat.

[Michal Kubeček]

Já třeba D-Bus používám na dálkové ovládání ktorrentu. :-) Podstatnější samozřejmě je, co si přes něj povídají jednotlivé programy mého desktopového prostředí, ale přiznávám se dobrovolně, že nemám čas ani náladu to zjišťovat.

[Sten]

Na dálkové ovládání KTorrentu mi přišel lepší plugin KTorrent Web Interface, ale samozřejmě záleží, odkud se to ovládá

[Michal Kubeček]

V mém případě většinou z shellového skriptu spouštěného přes ssh. Občas taky používám D-Bus na posílání zpráviček na IRC prostřednictvím konversation.

[Josef Kufner]

Například Psi se odpojí těsně před uspáním počítače právě díky eventu oznámeném po dbus.

[pavlix]

Zrovna jsem přemýšlel, jestli mi tohle funguje, když nemám žádnou z těch fancy věcí jako Gnome nebo systemd. Mám pocit, že na mém současném systému co není nahookované v /etc/acpi, to nemá šanci.

[little.owl]

Posilani zprav po nejake SW komunikacni sbernici s protokolem mezi procesy/moduly/aplikacemi je elegatni zpusob IPC a cela rada OS a systemu je na tom zalozena, muze to byt i jediny zpusob komunikace.

Na otazku k cemu to je pro vas dobre je tezke odpovedet, stejne jako k cemu je pro vas dobra knihovna libXY. Pokud ji vase aplikace nepouzivaji, je vam k nicemu a Dbus ma tu vyhodu, ze ho muzete vyradit a aplikace jsou diky protokolu vesmes schopne dale fungovat, byt treba s osekanou funkcionalitou.

Ja mam treba daemon, bezici na pozadi, monitorujici build server a vypocetni server, a posilajici zpravy pres Dbus, notifikujici me kdyz neco selhalo ci bylo dokonceno.

-----------------

S kdbus zadny dbus-daemon uz nebude potreba, bude to jen normalni lib a nebudete mit pomalu co vypinat, jak krute.

[Heron]

stejne jako k cemu je pro vas dobra knihovna libXY

Knihovnu libXY mi nikdo 10 let necpe do OS. Mě by byl dbus ukradený, stejně jako desetitisíce ostatních projektů, které jistě mají své uživatele a příznivce. Jenže, na rozdíl od desetitisíců ostatních projektů se bůh ví proč některé (mající jak na potvoru společné vývojáře) projekty nestále cpou kam nemají. Což by také samo o sobě nevadilo, kdyby se jejich tvůrci nesnažili o jedinou správnou (TM) cestu. Ostatně diskuse o NM, systemd, pa, kdbus jsou většinou právě o tomto.

Ja mam treba daemon, bezici na pozadi, monitorujici build server a vypocetni server, a posilajici zpravy pres Dbus, notifikujici me kdyz neco selhalo ci bylo dokonceno.

Pravda, nic z toho by bez DBUS nešlo.

S kdbus zadny dbus-daemon uz nebude potreba, bude to jen normalni lib a nebudete mit pomalu co vypinat, jak krute.

Naštěstí existují i jiné OS.

[little.owl]

Knihovnu libXY mi nikdo 10 let necpe do OS.

Pokud ji aplikace pouziva a zavisi na ni, tak ji tam mate, a ve vetsine pripadu nemate ani volbu ji nepouzit.

projekty nestále cpou kam nemají.

Znovu, to je zalezitost programatora aplikace, jake IPC mechanismy a knihovny pouzije.

Pravda, nic z toho by bez DBUS nešlo.

Slo, ale bylo by to X krat slozitejsi, plno casti desktopu ma Dbus integraci.

Naštěstí existují i jiné OS.

Ja chapu averzi vuci stavajici implementaci Dbus, ostatne proto se to predelava. Co nechapu je averze vuci IPC zalozenem na posilani zprav na systemove sbernici s protokolem.

[Sešívaný]

Ja chapu averzi vuci stavajici implementaci Dbus, ostatne proto se to predelava. Co nechapu je averze vuci IPC zalozenem na posilani zprav na systemove sbernici s protokolem.

No, ale je pod tím podepsaný Lennart, tak proč si nehodit kamenem? Je to teď přece v módě, ne?

[Heron]

Pokud ji aplikace pouziva a zavisi na ni, tak ji tam mate, a ve vetsine pripadu nemate ani volbu ji nepouzit.

Tak samozřejmně. Ale pořád mám volbu nepoužít tu aplikaci.

Znovu, to je zalezitost programatora aplikace, jake IPC mechanismy a knihovny pouzije.

To je zajisté pravda, ale už teď jsou tu případy, když místo např. signálů se použije dbus. Viz onen příklad s Psi. Místo poslání jednoduchého signálu ta aplikace zavisí na nějaké další službě. Zbytečně.

Ja chapu averzi vuci stavajici implementaci Dbus

To je asi špatně pochopeno, já proti dbus nic nemám. Nic proti němu nemám to té doby, dokud mi jej nikdo necpe. 10 let jsem jej z OS odstraňoval celkem bez následků. Teď se to cpe do jádra. (Vyhodíš ho dveřmi, vrátí se ti oknem -- v tomto případě to má i hořkou souvislost s jiným OS)

Co nechapu je averze vuci IPC zalozenem na posilani zprav na systemove sbernici s protokolem.

O tom jsem tu nikdy nepsal.

[Sešívaný]

To je asi špatně pochopeno, já proti dbus nic nemám. Nic proti němu nemám to té doby, dokud mi jej nikdo necpe. 10 let jsem jej z OS odstraňoval celkem bez následků. Teď se to cpe do jádra. (Vyhodíš ho dveřmi, vrátí se ti oknem -- v tomto případě to má i hořkou souvislost s jiným OS)

No a ty máš v jádře vždy jen to, co používáš? Někdo ti nutí všechny moduly z upstreamu? IMHO záleží na tom, jestli software, který používáš, dokáže fungovat bez dbus, ale to není problém dbus nebo kdbus, ale tvůrců toho softwaru. Záleží na nich, nikdo jim pistol u hlavy nedrží.

[Heron]

Z veřejných diskusí o tom, jak se do distribucí dostávají Lennartoviny jsem takto optimistický pocit tedy neměl. Ze soukromých rozhovorů s určitými lidmi jsem se dozvěděl, jak a za jakým účelem se do distribucí dostávají určité komponenty, přičemž na veřejnosti se to prezentuje jinak.

Nejsou to žádné záhadné konspirační moduly od NSA, je to normální software, který by asi leckdo i chtěl, ale jde o to, že ven se účel toho, proč je to v distru moc neprezentuje (jinými slovy, někdo chce otestovat software, který se na desktop / běžný server moc nehodí, hodí se úplně jinam, ale na desktopu se dá část dobře vyzkoušet). Omlouvám se, že nebudu konkrétní, ale tahle nečistá hra mi určitou společnost spojenou s linuxem dost silně znechutila.

[Bedňa]

To ja som počul, že na konferenciách nevychádza z budovy Všade ho majú radi.

[pavlix]

To ja som počul, že na konferenciách nevychádza z budovy

Je otázkou, kolik takových nesmyslů mezi lidmi, co na konference nejezdí, koluje.

[Bedňa]

Takže je to ten typ, čo si po prednáške vyráža sadnúť na jedno?

[Stanislav Brabec]

Co jsem si všiml, tak je na poměry linuxové komunity velmi dobrý řečník. Jestli pak chodí na pivo, to nevím.

[Sešívaný]

No, popravdě nevím, které části myslíš, protože ani jeden ze svých projektů nezačal Lennart z popudu svého zaměstnavatele. A AFAIK to neplatí ani o kdbus. Ano, jsou věci, které tlačíme třeba do Fedory, i když jsou pro většinu jejich uživatelů asi zbytečné. Jsou to třeba pokročilé věci v partitioningu Anacondy, LVM ve výchozím stavu zapnuté, zapnutý SELinux (i když potom, co ho nasadil i Google do Androidu, se nedá říct, že by to bylo pro běžné uživatele úplně zbytečné). Nicméně mi nikdy nepřišlo, že by si někdo vymýšlel zástupné důvody. Naopak se o nich veřejně ví, že tam jsou protože Fedora funguje jako upstream RHELu. Přijde mi, že takovéto teorie si vytvářejí lidi, kteří s danými technologiemi prostě nesouhlasí a důvody, proč by měly být v dané distribuci, prostě nepovažují za dostatečné nebo relevantní. To ale neznamená, že někdo nutně uvádí někoho v omyl.

[Heron]

a důvody, proč by měly být v dané distribuci, prostě nepovažují za dostatečné nebo relevantní

Ona je to taky otázka času, kdy se daný produkt do distribucí dostane. Asi se nebudeme tvářit, že projekty jako PA, NM apod se do dister dostaly až ve chvíli, kdy byly stoprocentní náhradou za minulé způsoby řešení. Spousta věcí se dodělávala postupem času. Ono možná, že kdyby někdo počkal na to, až budou hotové, tak by jejich přijetí bylo poněkud lepší.

[Michal Vyskočil]

Ona je to taky otázka času, kdy se daný produkt do distribucí dostane. Asi se nebudeme tvářit, že projekty jako PA, NM apod se do dister dostaly až ve chvíli, kdy byly stoprocentní náhradou za minulé způsoby řešení. Spousta věcí se dodělávala postupem času. Ono možná, že kdyby někdo počkal na to, až budou hotové, tak by jejich přijetí bylo poněkud lepší.

Release often, release early.

Jinak celá sranda s tím, "až budou hotové" je v

a) dokud se to nezačne testovat ve skutečných nasazení, nikdy to hotové nebude

b) software není nikdy hotový

c) Perfect is the enemy of good

d) takový Hurd je skvělým příkladem, jak se to dělat nemá

Komerční firmy platí (doufejme) armády QA, u open source software mají tuhle roli uživatelé.

[kavol]

a) dokud se to nezačne testovat ve skutečných nasazení, nikdy to hotové nebude

opravdu nevidíš rozdíl mezi začleněním do distra jako alternativy a nasazením jako defaultního řešení s házením klacků pod nohy jakémukoli pokusu alespoň umožnit použití jiných alternativ?

[Heron]

V zásadě už to napsal kavol.

Tohle je jen sbírka jakýchsi hesel vytržených z kontextu. Tím neříkám, že nejsou pravdivá, musí se ale používat správně.

Zrovna včera v době, kdy jsi napsal tento komentář, jsem byl na cestě na P2D2. Rok za rokem se opakuje situace, kdy vývojáři sami ohlašují na další verzi nějakou funkcionalitu, o které za rok vysvětlí, proč se tam nedostala. Většinou jsou ty důvody stejné. "Nebyli jsme s tím pachtem sami spokojeni, počkejte si další rok." Nevšiml jsem si, že by se proti tomu kdokoliv bouřil a požadoval onu funkci hned. Pro tento obor je mnohem lepší, když to bude hotové později, než když to rychle vadné. Samozřejmně, ty patche jsou k disposici a kdo chce, tak si to může zkoušet. To jen krátký odstavec k tomu release often, release early a software není nikdy hotový. A už vůbec jsem si nevšiml, že by byl PostgreSQL nějaký bezvýznamný nedodělaný projekt.

Takže tak. Není třeba nutit, lze jim to nabídnout jako alternativu. PA jsem věnoval poměrně mnoho času, měřil jsem kvalitu (věrnost vstup / výstup) zvuku, zkoušel jsem různá nastavení. Výsledek je jednoznačný, PA je pro HiFi v současném stavu zcela nepoužitelný. Pochopitelně, pokud to někdo chce, nezáleží mu na kvalitě zvuku a využije jiné vlastnosti tohoto softu (na 44.1kHz / 16b a defaultním resamplerem to funguje), může si vybrat PA. Jen mi vadí, že mi někdo PA vnucuje na úkor ostatních systémů. A tak dále.

Jinak celá sranda s tím, "až budou hotové" je v

Ještě poslední poznámku. Ano, všechny ty poznámky a poučky, které jsi napsal, fungovaly roky. Projekty se vyvíjely a získávaly si prízeň tím, že prostě byly lepši, než nějaké jiné. Postupně, evolucí. Tohle ale u Lennartovin z různých důvodů neplatí. Ty projekty se bůh ví proč "prostě" nasadí (možná je to nějaké managerské rozhodnutí jak píše Michal Kubeček), v jednom případě i já vím (mám info z jednoho zdroje uvnitř) že se jeden projekt nasadil z jiných důvodů, než se prezentuje ven. Takže min. nějaké náznaky tu jsou. Už to není boj o to, aby byl projekt lepší než jiný, už to není o letech práce na získávání si přízně, už je to i o managerech.

[lkajlkj]

Jo, pokrocile veci v partitioningu anacondy. Pote co si na tu zasranou shitku stezovala cela firma, tak ste se konecne uracili to tam "blahosklonne" vratit a ted z toho delas jak ste desne cool? To mi prijde jako desna idiocie

[little.owl]

Tak samozřejmně. Ale pořád mám volbu nepoužít tu aplikaci.

Ano. Pokud ji nejde spustit ci prelozit bez potreby Dbus, je to nejlepsi volba.

To je zajisté pravda, ale už teď jsou tu případy, když místo např. signálů se použije dbus. Viz onen příklad s Psi. Místo poslání jednoduchého signálu ta aplikace zavisí na nějaké další službě. Zbytečně.

Tam jde o mnoho dalsich veci. Chcete zjistit jestli vam bezi screensaver a user je away? Jestli je ve skupine na Jabberu nekdo aktivni a poslat mu zpravu? Jestli vam pri prijmuti SIP hovoru nejakym SW telefonem bezi nejaky torrent a treba ho po dobu hovoru ho pozastavit ci treba jen ztlumit/pozastavit prehravac? Jestli vam bezi nejaky fullscreen player a vypnout screensaver ci notifikace? Chcete to vsechno delat pres nejake signaly? Zkuste to a zkoncite taky u standardizovaneho protokolu a dalsi knihovny, a message sbernice je lepsi nez signaly.

To je asi špatně pochopeno, já proti dbus nic nemám. Nic proti němu nemám to té doby, dokud mi jej nikdo necpe. 10 let jsem jej z OS odstraňoval celkem bez následků.

Jeste jste mi nevysvetlil proc. Pokud to vase aplikace potrebuji, je lepsi to tam nechat, pokud nikoliv, je to zbytecne to tam mit; nic jineho mezitim neni.

Teď se to cpe do jádra.

Nejste jediny uzivatel kernelu a jini uzivatele to potrebuji. IPC mechanismus na bazi posilani zprav se v kernelu pred Lenartem pokousela treba implementovat Nokia (po zklamani z performance Dbus), pak Google (Binder), Genivi (AF_BUS) a ted GKH/LP/KS. Proc vam to ve stavebnici kernelu vadi?

[Honza Jaroš]

Chcete zjistit jestli vam bezi screensaver a user je away?

Ano, to chci! V Kopete nebo Psi (používám KDE). Jak na to?

Jsem schopen přes D-BUS přepnout status na jiný, ale zjistit ten aktuální se mi nějak nepodařilo, buď qbusviewer neukazuje všechno, nebo to tyhle dva kecálci neumí. Nebo jsem slepej.

[little.owl]

Pouzivam Gnome a monitoruji zmeny screensaveru - bezi => jsem pryc, na jabber pouzivam Pidgin, kde lze v pythonu dostat pres dbus list aktivnich uzivatelu. Chtel bych to predelat na Telepathy, ale je to na me ponekud slozite a chtelo by to vice casu, a to by melo byt i v KDE.

[pavlix]

Telepathy je nejen komplikované, ale i zabugované. Jednu dobu se mi ta myšlenka hodně líbila, ale dneska bych se spíše přikláněl k explicitnějšímu service managementu v rámci session.

[little.owl]

Zatim mi horsi prislo Empathy.

Kdyz te tak posloucham, tak ted jedes na Gentoo s openboxem, ne?

[little.owl]

Mam pocit, ze u Pidginu status taky zmenit pres dbus nejde, ale uz si to nepamatuji.

[Honza Jaroš]

U Pidgina mi to šlo přes purple-remote a mám pocit, že to taky komunikovalo přes dbus. Normálně jsem svůj aktuální status zjišťoval i nastavoval. U Kopete nebo Psi ho jsem schopen přes D-Bus nastavit, ale nevím, jak ho zjistit.

Mám cyklickou změnu statusu namapovanou na čudlík ThinkVantage na ThinkPadu a u Pidginu jsem to měl v závislosti na aktuálním stavu. U Kopete si bohužel aktuální status musím ukládat při přepnutí do souboru, což samozřejmě nereflektuje přepnutí statusu standardními prostředky.

Asi bych mohl splácat nějaký feature request, ale zase tolik mě to nepálí...

[Heron]

Tam jde o mnoho dalsich veci. Chcete zjistit jestli vam bezi screensaver a user je away? Jestli je ve skupine na Jabberu nekdo aktivni a poslat mu zpravu? Jestli vam pri prijmuti SIP hovoru nejakym SW telefonem bezi nejaky torrent a treba ho po dobu hovoru ho pozastavit ci treba jen ztlumit/pozastavit prehravac? Jestli vam bezi nejaky fullscreen player a vypnout screensaver ci notifikace? Chcete to vsechno delat pres nejake signaly? Zkuste to a zkoncite taky u standardizovaneho protokolu a dalsi knihovny, a message sbernice je lepsi nez signaly.

Chcete to vsechno delat

No upřímně řečeno nic z výše uvedeného dělat nechci a u každé jednotlivé věci by se dalo diskutovat proč. Je také k zamyšlení, zda se to vůbec řeší na správné vrstvě. (Aneb všechny moje představy o tom, co všechno má a nemá být součástí zvukové vrstvy vzaly za své, když jsem si mezi domácí pracovní stanici a zvukovou aparaturu připojil mixážní pult.)

IPC mechanismus na bazi posilani zprav se v kernelu pred Lenartem pokousela treba implementovat Nokia (po zklamani z performance Dbus), pak Google (Binder), Genivi (AF_BUS) a ted GKH/LP/KS.

Kdysi jsem měl nad stolem takový nápis: Even if you are a minority of one, the truth is the truth. To, že to někdo používá ještě neznamená, že to je dobře.

Proc vam to ve stavebnici kernelu vadi?

Protože jsem přesvědčen, že to neprospěje vývoji lepšího OS. Už takhle se do linuxu dostávají věci, které se dříve kritizovali u jiných OS (zejména tedy Windows). Je to prostě desktopovatění Linuxu (za stavu, kdy je desktop mrtvý). Místo toho, aby se věci dělali správně, tak se dbá víc na to, aby to bylo použitelné na desktopu. Patche do jádra pro úpravu FS při práci špatně napsaných appek, patche na to, by se nesekal kurzor, různé zásahy do grafiky, zásahy do scheduleru apod. Z mnoha důvodů si myslím, že to je špatná cesta. Samozřejmně, podle mě se nikdo řídit nebude.

[little.owl]

Je také k zamyšlení, zda se to vůbec řeší na správné vrstvě. (Aneb všechny moje představy o tom, co všechno má a nemá být součástí zvukové vrstvy vzaly za své, když jsem si mezi domácí pracovní stanici a zvukovou aparaturu připojil mixážní pult.)

Ty vrstvy hlavne potrebuji nejak komunikovat, a prave message bus podporuje modularitu.

Even if you are a minority of one, the truth is the truth.

A ci subjektivni verzi pravdy mate na mysli?

Je to prostě desktopovatění Linuxu (za stavu, kdy je desktop mrtvý).

Pozadavky na kdbus nejsilneji vzdy prichazeli z embedded sveta, at se jednalo o telefony (Nokia/Google) ci automotive (Genivi), desktop do tohoto moc netahejte.

[Josef Kufner]

Je to prostě desktopovatění Linuxu (za stavu, kdy je desktop mrtvý).

Pozadavky na kdbus nejsilneji vzdy prichazeli z embedded sveta, at se jednalo o telefony (Nokia/Google) ci automotive (Genivi), desktop do tohoto moc netahejte.

A desktop by z embeded světa pár věcí potřeboval. Desktopová vere Androidu by mohla být velice zajímavá.

[Heron]

Jen to ne. Asi fakt patřím do jiného světa.

[Drom]

+1, brrr, až sem se otřásl!

[Michal Kubeček]

IPC mechanismus na bazi posilani zprav se v kernelu pred Lenartem pokousela treba implementovat Nokia (po zklamani z performance Dbus), pak Google (Binder), Genivi (AF_BUS) a ted GKH/LP/KS.

Ještě si vzpomínám na nějaký pokus o multicasting nad PF_UNIX sockety, ale to IIRC David Miller zarazil hned v zárodku.

[little.owl]

Pravda, pred AF_BUS byly jeste nejake pokusy timto smerem.

[Stanislav Brabec]

Ja chapu averzi vuci stavajici implementaci Dbus

To je asi špatně pochopeno, já proti dbus nic nemám. Nic proti němu nemám to té doby, dokud mi jej nikdo necpe. 10 let jsem jej z OS odstraňoval celkem bez následků. Teď se to cpe do jádra. (Vyhodíš ho dveřmi, vrátí se ti oknem -- v tomto případě to má i hořkou souvislost s jiným OS)

Nikdo vám nebrání napsat patch do aplikace na --disable-dbus, v němž bude alternativní kód, který místo volání libdbus bude používat třeba socket() a select() nebo poll() a výsledky si bude parsovat sám? Akorát, že si ho pak budete asi muset sám udržovat, protože většina lidí by s ním přišla o výhody, které jim dává DBus. Třeba takové libnotify si bez DBusu moc nedovedu představit.

[pavlix]

Nikdo vám nebrání napsat patch do aplikace na --disable-dbus, v němž bude alternativní kód, který místo volání libdbus bude používat třeba socket() a select() nebo poll()

Prakticky každý framework s hlavní smyčkou má nějakou abstrakci nad asynchronním IO multiplexingem. V tomto případě je argument komplexitou nesmyslný, vzhledem k tomu, že ten wrapper bývá podstatně jednodušší a příjemnější než wrapper na D-Bus.

a výsledky si bude parsovat sám?

Pro většinu účelů není D-Bus dostatečně typově bohatý a parsing dat z D-Busu je prakticky stejně komplikovaný jako parsing surových dat. Projekty vyžadující zpětnou a dopřednou kompatibilitu tak jako tak přecházení na předávání dat pomocí polí stringů.

Akorát, že si ho pak budete asi muset sám udržovat, protože většina lidí by s ním přišla o výhody, které jim dává DBus.

Které konkrétně?

Třeba takové libnotify si bez DBusu moc nedovedu představit.

Skutečně? Já vcelku bez problémů.

[Stanislav Brabec]

Akorát, že si ho pak budete asi muset sám udržovat, protože většina lidí by s ním přišla o výhody, které jim dává DBus.

Které konkrétně?

Třeba broadcast událostí, na který se může připojit libovolná aplikace, a nad nimi vytvářet pravidla a syntetické události. Například: Příchozí hovor v jakékoliv (daný standard podporující) telefonní aplikaci => ztlum jakýkoliv (daný standard podporující) přehrávač, a lze-li, dej pauzu. V aplikaci A běži funkce B => změň chování screensaveru. Jakýkoliv přehrávač (daný standard podporující) se přepnul na celou obrazovku => nastav v jakémkoliv IM (daný standard podporující) stav Zaneprázdněn.

Třeba takové libnotify si bez DBusu moc nedovedu představit.

Skutečně? Já vcelku bez problémů.

Systémový oznamovací démon pak potřebuje, aby všechny zprávy chodily v jednotném tvaru. Takže skončíte na tom, že bude stejně třeba udržovat nějaký sdílený soket oznamovacího démona, nad ním API, řešit konflikty při současném zápisu, situaci, že události nikdo nečte, řešit, jak vracet zpět kliknutí atd.

[little.owl]

Tam jde hlavne o ten protokol a jeho implementaci ...

[David Jaša]

ubus na openwrt taky vypínáš?

[Heron]

Nepoužívám OpenWRT. Jinak nechápu, kam tím otázka míří.

[Pev]

"K dispozici jsou obalení pro širokou řadu jazyků

Proč ne API?

Díky za překlad.

[ebik]

Obalení a API se mírně liší. Pod pojmem API pro různé jazyky rozumím jedno API. Pod pojmem obalení pro různé jazyky rozumím převod do konvencí danného jazyka - tedy například vyrobení objektů, které v původním rozhraní nejsou, ale často se v danném jazyce jako pomocné objekty vyskytují. Pokud tedy dbus umožňuje předat filedeskriptor, pak v obalení předpokládám objekt, který se pro práci se soubory v danném jazyce používá nejčastěji. V API bych klidně čekal zase jen integer jako identifikátor filedeskriptoru - prakticky každý jazyk pak má něco jako funkci openfd().

Nicméně to je jen můj pocit, a jak je to doopravdy s dbusem nevím.

[Pev]

Vím, že to není přesné, přesnější je binding, to už zase není opravdu česky. Jen mám dojem, že obalení je zase až moc násilně česky.

[Josef Kufner]

Já bych to buď nepřekládal, nebo napsal,že to API (jednotné číslo) je k dispozici pro mnoho jazyků.

[Sten]

IIRC se pro binding v češtině používá napojení nebo navázání. Pod obalením bych si představil spíš nějaký wrapper.

[petr_p]

Rozhraní pro širokou řadu jazyků.

[debil]

LP je magor co vse rozvrta a nahradi to monolitem z jakeho nam bude jeste dlouho blbe.

nadruhou stranu (avsak necet jsem original), argumentace pro tento navrh ma smysl. drzim palce at se zadari!

[pavlix]

LP je magor co vse rozvrta a nahradi to monolitem z jakeho nam bude jeste dlouho blbe.

A dobře nám tak.

[frdrx]

Bravo Lennart Poettering!