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.
Vývojové jádro 3.17-rc3 vyšlo dne 31. srpna (oznámení). Linus k tomu řekl:
Podle očekávání je větší než rc2, protože se všichni zjevně vrátili z Kernel Summitu a tak. Naštěstí ale není o tolik větší než rc2 a neděje se nic tak zvláštního, takže prostě budu ignorovat všechny ty námitky o létě a doufám, že všechno půjde dobře.
Stabilní aktualizace: Minulý týden nebyla vydána žádná. Aktualizace 3.16.2, 3.14.18 a 3.10.54 procházejí v době psaní tohoto textu procesem revizí, můžeme je čekat 5. září nebo o něco později.
Bojím se jednoho – že nám unikají regrese výkonu, protože nové verze obsahují zisky i ztráty výkonu, z nichž některé se vyvažují. Po vydání řady hlavních verzí se výkon může zdát v pořádku, ale ve srovnání s vyzobáváním třešniček v distribučním jádru není situace zase tak růžová.
Mel Gorman (odkaz)
Řešení problému je úplně špatné a samozřejmě „oprava“ se použije jen na tu jednu instanci, které se ten problém může týkat, tedy té, která způsobila potíže tomu, kdo opravu předložil.
Nemám to za zlé autorovi, viním správce, který tu „opravu“ bez řečí zavedl.
To je bohužel v jádru velmi běžný jev, který z dlouhodobého hlediska způsobí vážné problémy s udržovatelností, ale to je samozřejmě jen názor jednoho nevrlého starého dědka.
Thomas Gleixner (odkaz)
Moje schránka doručené pošty vypadá, jako by se srazily dva poštovní vlaky přepravující e-maily a pak se na ně ještě zřítilo letadlo s nákladem e-mailů.
Matthew Garrett (odkaz)
Pár let už slýcháme, že nastupující zařízení s energeticky nezávislou pamětí (non-volatile memory, NVM) změní způsob našeho používání počítačů. Tahle zařízení by měla nabízet velké objemy paměti (pravděpodobně v řádu terabajtů), která je trvalá a přitom k ní lze přistupovat stejně rychle jako k pamětem RAM. Co s tak velkou trvalou pamětí budeme dělat, zatím není jasné, začíná se jí ale věnovat pozornost. Zdá se, že v ní budeme používat klasické systémy souborů. Bude je ale nutné poupravit, aby mohli uživatelé využít plný výkon NVM.
Je hračka na disk z NVM nasadit blokový ovladač zařízení tak, aby se tvářil jako každý jiný disk. V takovém případě se ale všechna data na disku kopírují do stránky ve vyrovnávací paměti jádra a zpět. Protože jde ale k datům přistupovat přímo, tohle kopírování je přinejmenším neefektivní. Uživatelé preferující výkon se raději chtějí vyhnout stránkování ve vyrovnávací paměti, kdykoli je to možné, aby mohli z disků NVM získat maximální možný výkon.
Jádro obsahuje nějakou podporu přímého přístupu do energeticky nezávislé paměti už od roku 2005, kdy byla do systému souborů ext2 přidána podpora XIP (execute-in-place). Tento kód umožňuje namapování souborů z přímo přístupného zařízení do uživatelského prostoru a data tak nemusejí procházet stránkovací vyrovnávací pamětí. Kód XIP se ale zjevně příliš nepoužívá a několik let se nevylepšuje, takže se současnými systémy souborů nefunguje.
Matthew Wilcox začal loni pracovat na vylepšení kódu XIP a jeho integraci do systému souborů ext4. Při tom zjistil, že není příliš vhodný pro potřeby současných systémů souborů; kód také obsahuje řadu nepříjemných konfliktů časování. A tak se jeho práce postupně změnila z rozšíření XIP na jeho náhradu. Jeho práce, v současnosti ve formě 21dílné sady oprav, se přibližuje stavu, kdy ho bude možné sloužit s hlavní větví. Dá se tedy čekat, že upoutá větší pozornost.
Tyto opravy nahrazují kód XIP novým subsystémem nazvaným DAX (tedy Direct Access, přímý přístup). Na úrovni blokového zařízení nahrazuje stávající funkci direct_access() ve struktuře block_device_operations.
Tato funkce přijímá číslo sektoru a hodnotu velikosti informující ke kolika bajtům chce volající získat přístup. Pokud je daný prostor přístupný přímo, měla by být vrácena základní adresa (jádra) a příslušné číslo rámce stránky. Číslo rámce stránky by se mělo použít v tabulce stránek při zajišťování přímého přístupu z prostoru uživatele do paměti.
Použití čísel rámců stránek a adres se může zdát trochu divné; většina jádra na téhle úrovni pracuje s pamětí pomocí stránky struktury. To zde ale z jednoho prostého důvodu nelze uplatnit: NVM není obyčejná RAM a nemá asociované žádné struktury stránek. Tyhle chybějící struktury mají řadu důsledků; asi nejvýznamnější je skutečnost, že NVM nelze kvůli přímému přístupu do paměti přenést do jiného zařízení. To například vylučuje nulové kopírování vstupně-výstupních síťových operací se souborem uloženým v zařízení NVM. Boaz Harrosh pracuje na sadě oprav umožňujících použití struktur stránek s NVM, nachází se ale zatím v poměrně rané fázi.
O jednu vrstvu výše se věnuje docela dost energie při prosazení podpory NVM ve vrstvě virtuálních systémů souborů, kterou by mohly používat všechny systémy souborů. Prozatím se připravuje zavedení podpory tohoto mechanismu do systému souborů ext4.
Andrew Morton je ale k téhle aktivitě poněkud skeptický. Jednou z prvních otázek je: proč nepoužít „vhodně upravenou“ verzi systému souborů v paměti (například ramfs nebo tmpfs). Bohužel se ale ukazuje, že tyto systémy souborů jsou připraveny pro paměti typu RAM, zatímco v případě typu NVM vhodné nejsou.
Podle Dava už jádro obsahuje pár „implementací trvalé paměti“, které potřeby NVM splní – systémy souborů XFS a ext4. Oba mohou hned pracovat s blokovými zařízeními využívajícími trvalou paměť. Chybí jim pouze možnost přímého mapování souborů do uživatelského prostoru bez použití stránkovací vyrovnávací paměti. A to by měl řešit právě kód DAX.
Existují i skupiny pracující na systémech souborů navržených přímo pro NVM, většina jejich práce je ale v počáteční fázi. Pokud všechno bude pokračovat stejně, dočkáme se jejich implementace do jádra nejdříve za několik let. Proto lze předpokládat, že si uživatelé disků z NVM vyberou některý ze stávajících systémů souborů.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Podpora systémů souborů v trvalé paměti...Kdyby raději konečně přijali do hlavní vývojové větve overlayfs nebo aufs. Případně obě řešení - aby si mohl vybrat každý co mu lépe vyhovuje. Udělali by lépe.
Tohle není argument, ale plácnutí do vody.
Ne. To je zcela zásadní argument. Byl v případě ReiserFS a je i v případě jakékoli jiné cool, ale nedotažené featury. Je mi jasné, že tento argument nezní dost přesvědčivě pro zástup lidí, kteří se vývojem jádra - a zejména hledáním chyb v něm - nezabývají, ale zato mají hromadu zkušeností typu "používám to už n let a prostě mi to funguje". Ale oni naštěstí nejsou tím, kdo rozhoduje, co bude v mainline.
V kernelu je řada věcí v mnohem horším stavu než zrovna tohle.
To, že je z historických důvodů v jádře kód, který je ošklivý a problematický, v žádném případě neospravedlňuje bezhlavé přidávání dalšího. Navíc se to až na řídké výjimky vesměs týká spíš koncových driverů zařízení. Filesystém je něco trochu jiného a pravidla jsou tam mnohem přísnější. Ne náhodou je poškození filesystému považováno za závažnější typ chyby než úplný pád systému.
Jasně. Jako byl v okamžiku přidání skvěle dotažený ext4.
Máte nějaké konkrétní příklady obtížně udržovatelného kódu nebo (v té době) známých vážných chyb, nebo jde jen o - vašimi slovy - "plácnutí do vody"?
Osobně mám dojem že se nové věci do jádra přidávají spíš z pozice ekonomické síly jejich vendora než kvality.
Na základě čeho máte ten pocit? Pokud za něčím stojí ekonomicky silný subjekt, tak to samozřejmě hraje roli, ale spíš nepřímo: je pochopitelně jednodušší něco rozsáhlejšího vyvinout a dotáhnout do akceptovatelné podoby, pokud někdo zaplatí vývojáře, kteří by se tomu naplno věnovali.
Obávám se, že podobné konspirační teorie o tom, jak jacísi tajemní "oni" zlovolně brání začlenění užitečných featur do jádra, jsou jen názorným příkladem pravidla "čím méně toho o problematice vím, tím snazší je mít o ní jasno". Jakmile si dohledáte konkrétní pull requesty, námitky maintainerů a důvody odmítnutí, začne se ukazovat, že je to vlastně celé trochu jinak.
Jeden historický bud jen tak namátkou.Hádám, že jste se asi neobtěžoval přečíst si, v čem ten bug spočíval, že ne? Ten "bug ve filesystému" byl ve skutečnosti chybou aplikací, které nesprávně očekávaly nějaké specifické chování, v tomto případě že soubor je na disk zapsán okamžitě poté, co ho aplikace uzavře. Takové očekávání je chybné, protože nic takového garantováno není a pokud aplikace chce mít soubor skutečně okamžitě zapsaný na disk, musí si o to říct například pomocí fsync(). Opravovalo se to ve filesystému - pouhou změnou výchozího nasstavení IIRC - protože takhlě blbě napsaných aplikací bylo moc.
Věci za kterými stojí velké firmy (Red Hat, Oracle, Google) se dostaly do kernelu celkem bez keců poměrně rychle - přes to, že jejich použitelnost byla diskutabilní.Určitě máte nějaký příklad, že? Včetně té diskutabilní použitelnosti, prosil bych.
Aufs je s námi už poměrně dost dlouhou dobu, ale protože za jeho vývojem nestojí velká firma, tak v jádře stále není.Zatímco fakt, že je to 16000 nebo kolik řádků totálně nepřehledného kódu, ve kterém se vyzná asi tak jeden člověk, žádnou souvislost nemá...
Přitom nic nebrání tomu, aby to bylo přidané jako experimentální modul.Jakmile se to jednou dostane do jádra, musí se o to někdo starat. To brání tomu, aby to bylo přidáno jako experimentální modul. Slovo experimentální na tom nic nemění.
Pokud jde o overlayfs, tak podle toho co vím jde o věc napsanou přímo dle doporučení vývojářů kernelu. O zařazení se uvažovalo již u jádra 3.10 Dnes se připravuje jádro 3.17 a stále není začleněno ani jedno řešení.Podle rychlého googlení se na overlayfs stále pracuje - když o něj tak stojíte v mainline, můžete pomoci.
Věci za kterými stojí velké firmy (Red Hat, Oracle, Google) se dostaly do kernelu celkem bez keců poměrně rychle - přes to, že jejich použitelnost byla diskutabilní.
Příklad? To, že vy osobně něco považujete za těžko použitelného, zdaleka neznamená, že to nemůže být velmi užitečné pro druhé. Myslíte snad, že ty firmy, které jste jmenoval, jen tak pro zábavu financují vývoj něčeho, co nemají v úmyslu používat? Občas samozřejmě ano, ale většinou se investuje do toho, co má zřejmý smysl.
A hlavně: užitečnost je jen jednou z podmínek pro to, aby se kód dostal do mainline.
O zařazení se uvažovalo již u jádra 3.10 Dnes se připravuje jádro 3.17 a stále není začleněno ani jedno řešení.
Nepíšete ovšem proč. Díval jste se, jestli od té doby byly nějaké pull requesty, a pokud ano, jak bylo zdůvodněno zamítnutí?
předpokládám, že pokud by mělo jedno, nebo druhé řešení nějaké zásadní bugy, tak by se to nejspíš projevilo
To je velmi odvážný předpoklad. Linux se dnes používá na extrémně širokém spektru zařízení a velmi rozmanitými způsoby. Jsou chyby, které se projevují jen na určitých architekturách, jen s mnoha procesory (což pro někoho nemusí znamenat 64, ale spíš 4096), spoustou paměti nebo třeba mnoha SCSI zařízeními.
Mimochodem, jádro 3.10 vyšlo před necelými 15 měsíci. Z hlediska vývoje něčeho tak komplexního to není až tak dávno, jak to na první pohled vypadá.
Já přeci nemám nic proti tomu, že se do jádra přidávají věci důležité pro jiné, a které osobně nepoužívám.To o vás ale předřečník netvrdil, že ne? Jo a ten příklad chybí...
Nejsem vývojář kernelu a na sledování komunikace o tom co se kde šustne nemám čas.Ale když vám odpovídá člověk, který AFAIK do vývoje kernelu vidí, tak ignorujete, co říká...
Mě nedělá problém si čas od času kernel opatchovat, ale soudím že vývoj a údržba takových věcí mimo hlavní vývojovou větev sebou nutně nese opruz navíc.Ano, je pochopitelné, že byste byl radši, kdyby ten opruz někdo řešil za vás. Jenže ten někdo vůbec nemusí být původní vývojář toho kódu, ale někdo, komu to spadlo na hlavu poté, co se původní vývojář na kód vykašlal.
A řekl bych že v případě některých technologií je to spíš otázka politiky než zdrojového kódu. Z toho co vím se o to, že zatím k začlenění overlayfs nedošlo nejvíc zasloužila jedna ... která zakalila vodu a pak zase chcípnul pes.Takové tvrzení by bylo vhodné podložit odkazy na relevantní diskuzi třeba na LKML... jinak to není nic jiného, než to plácnutí do vody.
Obvyklé je, že konkrétní výhrady sdělí příslušný maintainer subsystému v odpovědi na pull request (nebo sérii patchů). Pokud tomu tak v tomto případě nebylo, pak očekávám, že vy poskytnete odkaz na e-mail, kterým byl pull request zamítnut, abychom mohli posoudit, zda šlo opravdu jen o vágní výmluvy. Pokud jste tu odpověď ve skutečnosti nečetl a přesto tady stále mlžíte o temných silách a moci peněz, pak to dost vypovídá o vaší věrohodnosti.
Já jsem například jako poslední našel tohle. Al Viro tam přednesl zcela konkrétní technické výhrady. Nejsa specialistou na VFS a filesystémy, netroufám si posuzovat jejich závažnost a relevanci. Vy ano?
Pokud tím člověkem co "AFAIK do vývoje kernelu vidí" máte být vyNe. Ten příklad věcí, které "se bez keců dostaly do mainline díky podpoře velké firmy přes to, že jejich použitelnost byla diskutabilní" asi nebude, co?
soudím že vývoj a údržba takových věcí mimo hlavní vývojovou větev sebou nutně nese opruz navíc
To rozhodně ano. Ale i tak tomu občas dá někdo přednost před tím, aby svůj kód upravil do akceptovatelné podoby.
Nejsem vývojář kernelu a na sledování komunikace o tom co se kde šustne nemám čas.
Přesto by neměl být takový problém, pokud vás overlayfs tak moc zajímá, dohledat příslušnou komunikaci ve veřejných archivech příslušných mailing listů. Rozhodně by to bylo přínosnější než bez dostatečných informací šířit mlhavé náznaky typu
A řekl bych že v případě některých technologií je to spíš otázka politiky než zdrojového kódu. Z toho co vím se o to, že zatím k začlenění overlayfs nedošlo nejvíc zasloužila jedna ... která zakalila vodu a pak zase chcípnul pes … ale jeho kód je stále údajně fuj fuj fuj. Takže jsme v situaci, kdy v mainline není pro jistotu nic.
A sorry, na pocit, že kdo nemaže, ten do jádra nejede, mám plné právo.
To určitě máte. Jen byste ho neměl vydávat za nic víc než za osobní pocit někoho, kdo to dění vlastně nijak moc nesleduje a ten pocit si utváří na základě kusých informací z druhé ruky.
Osobně mám dojem že se nové věci do jádra přidávají spíš z pozice ekonomické síly jejich vendora než kvality.
Proto také ignoruji trekkerovy a Kubečkovy výzvy abych dohledával věci, které momentálně stojí zcela mimo moji pozornost.
Aha. Takže na jedné straně vás overlayfs tak moc zajímá a jeho absence v mainline tak moc trápí, že po diskusích spřádáte konspirační teorie o tom, jak ho maintaineři bez vážného důvodu odmítají přijmout, ale na druhou stranu je zcela mimo vaši pozornost ověřit si, jak to je s tím (ne)začleněním ve skutečnosti (dogooglit se k tomu threadu, na který jsem odkazoval odpoledne, mi netrvalo ani pět minut). Zajímavé…
Začlenění do mainline podle mě výrazně zvyšuje šanci na to, že se najde někdo, kdo případné bugy najde, případně ne příliš dobrý kód napíše jinak a lépe.Ano, tuhle teorii zastávali i jiní. Zkusilo se to u btrfs a ukázalo se, že to zase tak moc dobře nefunguje, vývoji se pak stejně věnovali víceméně ti samí lidé, které tenkrát platil Oracle. Se stejnou myšlenkou vznikl staging strom a taky to není žádný zázrak. Proto na tenhle argument vývojáři mainline už neslyší, i přesto že si Aleš Kapica myslí, že u overlayfs by to určitě fungovalo.
Proto také ignoruji trekkerovy a Kubečkovy výzvy abych dohledával věci, které momentálně stojí zcela mimo moji pozornost.Ještě že je na co se vymluvit...
Zrovna začlenění Btrfs bylo pro mne doslova požehnání.Nesouvisí s rychlostí vývoje v mainline a mimo.
A rozhodně nemám pocit, že by tím jeho vývoj nějak utrpěl - právě naopak.AFAIK vývojáři jádra měli pocit opačný. A pokud říkáte, že nemáte čas sledovat vývoj jádra, tak oni ho IMO mají.
V podstatě je to jediný souborový systém, který svými možnostmi tvoří na linuxu protiváhu k ZFS.Taktéž nesouvisí s rychlostí vývoje v mainline a mimo.
A pokud si něco Aleš Kapica myslí, tak to taky dříve nebo později bude. Prozatím se mi nestalo, že bych v oblasti IT někdy vsadil na špatného koně.Ehm, Reiser4? Navíc jste stále mimo téma, nejde o žádné koně, ale o to, že začlenění do mainline projektům většinou nepomáhá k urychlení vývoje.
Evidentně však ten důvod unikl i vám
Na to, že mu - podle vás - unikl, ho popsal dost přesně. Přinejmenším podstatně přesněji než vy…
Nějak jsem si nevšimnul.
Očividně. Já ale ano.
Jediný link k věci byl od vás, jenže z doby kdy o jádře 3.10 ještě nebylo potuchy.
Byl to poslední (nejnovější) submit, který jsem našel. Pokud vy víte o nějakém novějším, očekávám, že se podělíte o odkaz. A mimochodem, pokud by byla tato série přijata, objevila by se v mainline právě ve verzi 3.10 (nebo, chcete-li, 3.10-rc1), takže je mi záhadou, z čeho vychází vaše tvrzení, že tehdy "o jádře 3.10 ještě nebylo potuchy").
V době, kdy jsem používal Reiser4 vývoj Btrfs teprve začal, takže nemyslím, že bych jeho používáním nějak šlápnul vedle.Opravdu nedokážete udržet myšlenku přes 2 příspěvky? Psal jste o sázení na špatného koně. Vzhledem k tomu, jak Reiser4 dopadl (nijak), vám ho jako dobrého koně těžko někdo uzná.
Pokud jde o vývojáře jádra, tak je vcelku logické aby dění kolem kódu sledovali. Jenže mě na rozdíl od nich, nebo některých mých kolegů, vývoj který bezprostředně souvisí s kernelem neživí.Přesto tady ale dáváte fundované názory na to, proč začleněn nebyl.
Evidentně však ten důvod unikl i vám, jinak byste uvedl odkaz na konkrétní s tématem související vlákno, místo toho otírání o mou osobu, jimž plevelíte tuhle diskuzi.Zajímavé, když vy něco tvrdíte, ale neuvedete příklad a nedáte link, je to v pořádku, protože "nesledujete dění okolo jádra". Když ho neuvedu já - protože je to hledání na půl minuty, což byste měl zvládnout - je to otírání o osoby a plevelení diskuze... LMGTFY: http://lwn.net/Articles/600106/ , třeba Dovolil bych si ocitovat první odstavec
Whiteout is now a special char device instead of a symlink, this breaks compatibility with previous versions. See attached conversion script (takes upperdir as argument).To mi opravdu nepřijde jako kód vhodný pro začlenění do mainline. Pokud nebudete chtít jenom plácat do vody, můžete si před další diskuzí dohledat reakce na ten mail, ze kterých je docela dobře vidět, že se ten kód pořád vyvíjí...
Překrytá vrstva je pro nás zajímavá spíš z opačného důvodu.Pro vás. Jenže někdo jiný může mít jiné potřeby mezi které patří možnost plně využívat overlay jako standardní filesystém. A standardní filesystém musí mít možnost mazat soubory.
Proto se hledá nějaké obecně použitelné řešení. Z praktického hlediska je to však zcela parciální problém.... jehož řešení nicméně zjevně není triviální.
Řekl bych, že k této změně bylo přikročeno právě proto, aby se vyšlo vstříc rozmarům vývojářů jádra
Na základě čeho byste to řekl? Na základě svých hlubokých znalostí VFS? Tak hlubokých, že aniž byste sledoval tu komunikaci (což jste sám přiznal), okamžitě poznáte, jestli je vhodnější řešení Miklose Szerediho nebo Al Vira?
Ale hlavně jde o to, abyste pochopil, že to, co se děje, je normální technická diskuse a přirozený vývoj, ne vrtošivé rozmary někoho (koho označujete hvězdičkami), kdo si postavil hlavu, protože toho druhého nemá rád nebo od něj nedostal úplatek.Tak zrovna o tomhle mám silné pochybnosti.
To je ovšem velmi svérázná (dez)interpretace.
Načež jako čertík z krabičky vyskočil Okajima se svými technickými připomínkami.
Takže ty připomínky nakonec jsou technické (i podle vás). To jsou mi věci… Nemluvě o tom, že Okajima není maintainerem příslušného subsystému, takže jeho výhrady vůbec nemusejí být důvodem k odmítnutí.
Ale jak už jsem řekl, mnohem větší problém vidím v tom, že do vydání 3.17 zbývá jen pár dnů.
Co vím, tak…
Raději si konečně přečtěte ty thready, ať můžete operovat něčím, co opravdu víte. A už jsem se ptal jednou: vy se opravdu cítíte tak kovaný ve VFS a filesystémech, abyste si troufal posoudit, které technické připomínky jsou relevantní "konkrétní" a které jsou jen pokusem o zdržování? (Kromě toho, že je mi záhadou, co by to zdržování komu vlastně přineslo.)
A pokud jde o pečlivost čtení. Szeredi hned v prvním mailu píše, že by chtěl kód začlenit do řady 3.18, takže mi uniká spojitost s vydáním stable verze jádra 3.17.
Asi to bylo naivní, ale doufal jsem, že bavíme-li se v diskusi pod Jadernými novinami, budou mít všichni zúčastnění aspoň základní představu, jak vývojový cyklus funguje. A bude jim tedy jasné, že aby se kód implementující novou funkci (přesněji cokoli, co není jen oprava chyby) dostal do 3.18, je potřeba, aby byl přijat do příslušného subsystému před začátkem příslušného merge window, tj. před vydáním 3.17 (přičemž čím dříve, tím lépe). Teoreticky je sice možné, že by to prošlo i po jeho začátku, ale bylo by to hodně neobvyklé a Linux takové věci nevidí rád (velmi mírně řečeno).
Na to mu Szeredi odpověděl, s tím že co si pamatuje, tak aufs aby mohlo fungovat, některé věci z mainlainu odstraňovalo.Jste si jistý, že jste si tu diskuzi přečetl pořádně?
Pokouší se o to spousta lidí a jak lze snadno nahlédnout v gitu, docela často i úspěšně. Jen to chce rozumět tomu, jak věci fungují a nebrat každou připomínku jako akt vyhlášení osobní války.
Jistě, někdy je frustrující, když třeba posíláte čtvrtou verzi patche kvůli coding style a pořád ještě nikdo nenapsal, jestli je tohle vůbec správný způsob, jak problém řešit. Ale stačí pár zkušeností s hledáním a opravováním problémů ve zdrojácích projektů (i výrazně menších), které takhle přísnou "štábní kulturu" nemají, aby člověk pochopil, že to není samoúčelné.
asi dvakrát jsem nějaký one-liner poslal a stačilo mi ke spokojenosti, že to lidi najdou googlem v LKML, když už se nikdo nenamáhal to zařadit
Málokdy stačí jen LKML (pokud vůbec u něčeho). Je potřeba si přečíst Documentation/SubmittingPatches
a podívat se do MAINTAINERS
(nebo rovnou použít scripts/get_maintainer.pl
). Když se to pošle správným adresátům, bývá reakce hodně rychlá.
mix technického deliria (sada dvě stě patchů)
Já jich ve větvi overlayfs.current
vidím patnáct.
Moje schránka doručené pošty vypadá, jako by vlak naboural přepravující e-maily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.nemělo by to být spíš
Moje schránka doručené pošty vypadá, jako by naboural vlak přepravující e-maily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.?
Moje schránka doručené pošty vypadá, jako by vlak přepravující e-maily naboural do jiného vlaku přepravujícího emaily a pak se na něj ještě zřítilo letadlo s nákladem e-mailů.
Tohle taky moc ne:
většina jádra na téhle úrovni pracuje s pamětí pomocí stránky struktury
Dokud jsem si to otrocky slovo od slova nepřeložil zpátky, vůbec jsem netušil, co by mohla být ta "stránka struktury" (hint: je-li něco v originále "psacím strojem", je to obvykle kód a ten je lepší nepřekládat).
A o kousek dále:
To například vylučuje nulové kopírování vstupně-výstupních síťových operací se souborem uloženým v zařízení NVM.