Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
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.
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.
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í.
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í.
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.
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.
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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
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.
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 :)
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 ...
Každému je jasné, že keby RedHat umrel, zomrie aj systemd a ďalšie megalomanské projektyPsano 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.
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.
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)....
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.
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
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.
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.
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.
Jj s týmto prirovnaním sa nedá než súhlasiť.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
jenže elektronka => tranzistor => IO je skutečný vývojO tom nepochybuji. Pointa byla v tom, ze lide se museli vzdy ucit, a ty zmeny probihaly vzdy na pochodu.
stát se rentiérem; ti méně schopní (jako já) aspoň být připraveni změnit oborNa 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.
nějakým pěkným mlejnuMlejn => asi voda pobliz => pryc.
nejde o konkrétní projekty, ty jsou pouze indikátorem nezdravého stavu celého oboruNemyslim, narozdil od treba usr move mi davaji smysl.
v zájmu zachování zaměstnání se takovýmto příležitostem vyhýbámAni Rezza vas neuhlida?
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 dalekono, až na ty Beskydy to mám vpodstatě v plánu.
Mlejn => asi voda pobliz => pryc.proč?
nejde jen o to, jestli to vůbec dává smysl, ale třeba i (nebo spíš hlavně?) o provedenínejde o konkrétní projekty, ty jsou pouze indikátorem nezdravého stavu celého oboruNemyslim, narozdil od treba usr move mi davaji smysl.
Ani Rezza vas neuhlida?copak je to snad nějakej bodyguard?
Mozna zaplavova oblast, jak jsem zazil, romanticke je to do doby dokud neprijde povoden.Mlejn => asi voda pobliz => pryc.proč?
A to neni jedna z jeho funkci zajistit, abyste se tam neprali?Ani Rezza vas neuhlida?copak je to snad nějakej bodyguard?
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
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ě.
Jsou ty věci skutečně nové?Jak pro koho.
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éhono, 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"
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.
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 kdbusA 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čiaNejnovejsi LFS.
Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pametTo ří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..
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.
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é.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áš.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.
(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 ...
Bud jste clovek majici stesti nebo vysoky prah vnimani problemu ci spatnou pametTak 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ť.
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ů.
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.
Alebo tiež verzia bez systemd tak stabilná ako aj vývojová.posledná záchrana v LFS a to hádam nezničiaNejnovejsi LFS.
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
to je hobby projektJedna 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 synonymaPak 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 pesA 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.
ř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)to je hobby projektJedna 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 snahu zničit vše ostatní?"velký" a "megalomanský" nejsou synonymaPak mi neni jasne, co tomu vycita.
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
snaze vyhovět, co by kdo v jádře potřebovalUvidime 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 systemdKlicova je poptavka, byl tu prostor a on ho obsadil, zbytek je spekulace.
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íšř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.
Ano. Nekteri lide jsou vhodnejsi pro implementaci noveho projektuto ale nemluvíš o Lennartovi, že?
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?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.
viz výše, nebo jinak, poptávku po jabkách těžko uspokojí shnilý rajčatanýbrž kde by byl systemdKlicova je poptavka, byl tu prostor a on ho obsadil, zbytek je spekulace.
nevycházím z ničeho tajného, ostatně spousta informací a odkazů padla už i tadyNaznaku 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.
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
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 nenabootovaljako 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?zatím asi ano, ale viz výše
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ý?)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.
"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 ..)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.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 ...
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 nenabootovalPokud 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.
eh? říkám že neprošlo? - ptám se proč ...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!
hm, a co takhle trvat na tom, aby optional byly oba, druhý nemusel záviset na prvním, a uživatel si mohl vybrat?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?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?
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... 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 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
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)
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 obloukemNe, 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 infoNo, pokud rozhovaci proces vypada takto:ale jeví se mi to tak, že si dělá co chce
Ahoj Jime, jak se mas, jak je v Raleigh?pak ano.
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.
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š ...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?
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?
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?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?
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ípoune, 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 se ale nedějeto není odpověď na mou otázku, to je naopak argument na podporu toho, že jsme se Lennartovu návrhu měli vyhnout velkým obloukemNe, tam je potreba review od dalsich lidi a korekce designu, to je problem one man show.
No, pokud rozhovaci proces vypada takto: ...no, v některých případech to nebude daleko od reality
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.
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ějeViz. 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.
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
no, takže si musím vybrat journald => nemůžu si vybrat ...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.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)
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 jinakno, 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.
Gentoo SELinux umí, pokud nejni vyladěnej, tak můžeš přiložit ruku k díluVedle Fedory testuji ted lehce opet Arch, ke Gentoo se take dostanu. Ano, take bych me zacit neco delat.a s tím rolling, no, mám dojem, že denně dostávám do Fedory nejmíň dvakrát tolik updatů, co do Gentoo ...
zhoršení již tak špatného, namísto aby se to na základě praktických zkušeností řešilo jinakA ja jsem optimista a verim, ze je to zhorseni docasne, protoze stejne nemate jinou moznost nez to opravit.
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 ;).
Problém ale je, že v takom prípade by pravdepodobne takmer nikto nepoužíval journald
Proč "problém"?
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…
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 ...?
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.
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.
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ů.
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.
return -EINVALIDCONTEXT;
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 :).
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ě.
Jen tak dal, kriplove z RedHeatu kripli Linux a pracujou na metamorfoze na desktopovy shit ala MS Windows. Congratz.
Tak ze se tu vytahuje Lennartovo jmeno, ale makal na tom nekdo jinej.To už je snad standardem, ne?
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
Psal jsem ze Greg je od RH ? Tak mi nevkladej do huby co jsem nepsal. Kay a Lennart kazdopadne jsou.
Deset let jeho používání ..
To už ho vypínám 10 let jo? Toto letí.
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.
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.
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.
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?
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.
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ží.
To ja som počul, že na konferenciách nevychádza z budovyJe otázkou, kolik takových nesmyslů mezi lidmi, co na konference nejezdí, koluje.
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ší.
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é.
a) dokud se to nezačne testovat ve skutečných nasazení, nikdy to hotové nebudeopravdu 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?
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.
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?
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.
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.
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.
A desktop by z embeded světa pár věcí potřeboval. Desktopová vere Androidu by mohla být velice zajímavá.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.
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.
Nikdo vám nebrání napsat patch do aplikace naJa chapu averzi vuci stavajici implementaci DbusTo 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)
--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.
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ů.
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.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ě?
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.Třeba takové libnotify si bez DBusu moc nedovedu představit.Skutečně? Já vcelku bez problémů.
LP je magor co vse rozvrta a nahradi to monolitem z jakeho nam bude jeste dlouho blbe.A dobře nám tak.