Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
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).
Příspěvek Jak přežít plánovanou údržbu DNS na blogu zaměstnanců CZ.NIC upozorňuje na historicky poprvé podepsání DNS root zóny novým klíčem dne 11. října 2018 v 18:00. Software, který nebude po tomto okamžiku obsahovat nový DNSSEC root klíč, nebude schopen resolvovat žádná data. Druhým důležitým datem je 1. února 2019, kdy významní výrobci DNS softwaru, také historicky poprvé, přestanou podporovat servery, které porušují DNS standard RFC 6891 i jeho předchůdce RFC 2671. Servery, které po 1. únoru nebudou odpovídat na dotazy s EDNS rozšířením přestanou z pohledu klientů fungovat a domény hostované na těchto serverech se stanou nedostupné. Další informace spolu s testovacím nástrojem a doporučeními k řešení problémů lze najít na webu dnsflagday.net.
Tiskni
Sdílej:
Vkladam do techhle zmen hodne nadeji, ze se budou divat na vec trochu min prednasrate.Přednasratost + násilné omezování přednasratosti = větší přednasratost. Nikdy menší. Akorát dostaneš o něco zdvořilejší a mnohem méně upřímnou odpověď.
Specificky - kdyby treba na mm kameni nesedel Andrew Morton, mozna by to tak moc nesmrdelo a dneska uz by Linux byl vhodnejsi i
Zrovna o MM mám barvité informace z první ruky (nebo druhé, záleží na definici) a jestli jsem tomu dobře porozuměl, kromě mírného až většího chaosu (Andrew Morton nevěří na git) je hlavním problémem právě to, že je hromada lidí, kteří se snaží za každou cenu protlačit změny, které jim z pohledu jejich specifického use case připadají naprosto nezbytné, ale (1) zkomplikují a zatemní kód a (2) zhorší chování jiným uživatelům s jinými vzorci užívání. No a někteří, když se jim to nepodaří, píší pak všude možně litanie o tom, jak správci MM odmítají řešit závažné a nezpochybnitelné problémy.
na masiny s vic, jak par MB RAM... (s notnou nadsazkou, ofc)
Asi tak šest (desítkových) řádů nadsázky. Ale to už jsme před časem probírali.
No, a presne zasadni a kompletni prekopani toho, s cim vlastne cca historie Linuxu zacala, je co by bylo IMHO potreba, poradny redesign od podlahy se zahrnutim vsech protichudnych pozadavku uz do navrhuU Hurdu určitě mají místo pro vývojáře
Kompletní překopání znamená, že se na několik let odtrhneš jednak od aktuálního vývoje, ale hlavně od reality. Budeš si hrát na vlastním písečku, vyrábět redesign od podlahy, pak vítězoslavně přijdeš se svým novým převratným řešením... a polovina uživatelů, na jejichž use-case jsi zapomněl nebo nedostatečně otestoval, tě pošle do prdele, že jim ten tvůj úžasný a výborně promyšlený udělátor přináší výkonostní regrese.
Revoluční řešení fungují akorát tak v marketingových blábolech... Evoluce, i když je to víc práce, nakoenc přináší lepší výsledky.
Pokud se nepletu, nove CoC rikaji, ze pokud se takhle bude chovat maintainer, tak uz maintainer nebude - aby prave neblokoval dany subsys na svem egu, k cemu se tenhle kult nasledovani zvrhne vzdycky.Tomuhle skutečně věříš? To by naivitou předčilo i tvoje předchozí "systemd je skvělé, protože je to aspoň nějaká změna" a) pokud tě ten maintainer pošle do háje s něčím, co bude vypadat jako hromada technických důvodů, proč tvojí změnu nezačlení - i když skutečným důvodem bude "jdi do prdele, nerozumíš tomu" - tak ho nikdo nevykopne b) není moc lidí, co by se hrnuli do správcovských pozic A ZÁROVEŇ měli schopnosti to dělat dobře. Vykopnout lidi, co splňují obě tyto podmínky, na základě stupidního CoC, je buď nerealistické, nebo cesta do pekel.
a) a ono je nekde receno, ze uz nemuzu odepsat a pseudo-technickym duvodum se, v ramci CoC, branit argumentaci? Kdezto kdyz mne posle do riti explicitne, mam o motivaci min se vubec Linuxem zabyvat (ale ted neresime mne, ale resim ruzne podobne opinionated vysoce produktivni "assholes", jako je Linus sam, kde clash Linusovo ego x Linusv2 ego, vede k tomu, ze Linusv2 neprichazi, rozhodne ne skillem 1:1, tlamou mozna ano...).
b) Proc asi? Nemohlo by to byt tim, ze kdyz chces antisocialni chovani od svyho maintainera (coz u Linuse melo body++) AND subsystem s rozumnou budoucnosti, mas problem, protoze se ty dve veci vylucuji? Clovek myslici do budoucna nebude na svoje lidi kricet, protoze vi, ze bude filtrovat rozumne myslici jedince a pritahovat extremisty, ne nutne se vsemi sdilenymi hodnotami stejne v extremu.
Ty ostatní věci nebudu radši komentovat, protože to stejně nemá smysl, ale tohle mi nedá:
Nemohlo by to byt tim, ze kdyz chces antisocialni chovani od svyho maintainera (coz u Linuse melo body++)
Reality check: člověk, kterému Linus zjevně důvěřuje nejvíc a kterého automaticky považuje za "muže č. 2" (což teď ukázal i prakticky) je Greg KH. Marně vzpomínám, kdy se Greg projevoval nějak "antisociálně", pokud je mu něco vytýkáno, je to spíš pravý opak.
Není to náhodou tím, že vidíš to nejhorší a zbytek si doplníš, protože vidíš, co chceš vidět?
Něco jako kdyby člověk posuzoval kriminalitu v ČR výhradně na základě sledování Krimi zpráv TV Prima? :-)
Já to přeci jen ještě zkusím…
Většina těch příkladů na téma "někdo nový přišel s geniálním řešením a zatuchlí maintaineři (a stávající vývojáři) se mu vysmáli" může z jiného úhlu vypadat trochu jinak. Třeba tak, že přišel někdo, kdo nemá s daným subsystémem moc zkušeností, předložil něco zajímavého, ale když byl upozorněn na konkrétní problémy, trval si na svém a ignoroval jejich zkušenosti a kulturu daného prostředí.
Když se třeba podívám na kontext, ve kterém padla ta "strašná" reference na Holy Grail, vidím, že autor patchsetu přes opakovaná upozornění, že BUG / BUG_ON není v dané situaci adekvátní, a vysvětlení proč, trval na tom, že podle něj to tam tak patří. Těžko říct, jestli neví, že ze stejných důvodů se i spousta historických použití BUG() a BUG_ON() postupně degraduje na (ratelimited) WARN(), WARN_ONCE(), prosté pr_*() a nebo dokonce vyhazuje úplně. Ale to jsou právě ty jemné detaily, které náhodnému externímu pozorovateli snadno uniknou.
Příklad z praxe. Nedávno se mi stalo, že mi Linus osobně odmítl patch. Někoho to možná překvapí, ale stalo se tak bez jediné vulgarity nebo urážky mne, mého příbuzenstva, domácího zvířectva nebo kohokoli jiného. Co je ale zajímavější, moje první reakce byla přesně taková, jakou cítím z vašich příspěvků: "Co to povídá, můj patch je dobře (tedy v2, která už byla mezitím odeslaná), je univerzálnější než ten jeho a zase o tolik složitější a ošklivější není."
Pak jsem se ale trochu zamyslel a došel jsem tomu, že (1) jeho řešení je opravdu přehlednější, (2) v situacích, kdy nefunguje, nefungoval ani předchozí kód a (3) pokud bychom rozšířili rozsah případů, kdy bude userspace spoléhající na empiricky vypozorované a ničím nepodložené chování fungovat, tak vlastně podpoříme špatné programátory, aby psali ještě horší programy.
Stejně tak potom tady bych se mohl urazit, že mi to vysvětluje jako nějakému prvňáčkovi, když stačilo upozornit na to jedno místo, kvůli kterému ta situace nastat nemůže. A nebo jsem si mohl říct, že nemám důvod v tom hledat za každou cenu něco špatného, že koneckonců neví, jestli mi to bude jasné z pouhého hintu, a že můžu vlastně brát jako poctu, že někdo s tak nabitým programem si najde čas podrobně to rozebrat.
Stejně tak mi na první pohled může připadat malicherné bazírování Davida Millera na detailech coding style; někdy (reverse Christmas tree) dokonce až absurdní. Ale po pár letech práce spočívající z velké části ve čtení a porozumění cizímu kódu, který vidím poprvé, musím konstatovat, že je zatraceně příjemné, když se - aspoň v core networkingu - můžu téměř spolehnout na to, že určité konstrukce budou vždy vypadat jedním konkrétním způsobem.
Co tím celým povídáním chci říct? Že často je opravdu problémem nedostatek empatie a neochota zamyslet se nad tím, jak to celé vypadá z druhé strany. Ale že zdaleka ne vždy je ten problém na straně maintainerů - a málokdy je jenom na jejich straně. Přijít někam namachrovaný až na půdu a začít všem vysvětlovat, jak to doteď všichni dělali úplně špatně a já jim teď ukážu, jak to má být správně, není nejlepší způsob, jak své geniální myšlenky prosadit, ani v práci, ani v open source projektu. Dokonce ani v případě, že mé nápady jsou opravdu geniální, oni to opravdu dělali všechno špatně a já tomu opravdu rozumím mnohem lépe - což je ale hodně zřídka. Takže se obávám, že pokud hodláte na LKML vystupovat v duchu, jaký jste předvedl (nejen) na začátku této diskuse, sebepřísnější CoC vám nepomůže.
Kdezto v pripade BUGu a zabijeni procesu pri spatnem chovani, je vylozene neuroticky a prehani to.
A právě proto jsem upozorňoval nejen na to, že jde o narážku ha Holy Grail, ale i na kontext. Ten vtípek totiž nepadl v první reakci na ten patchset, bylo to po opakovaném vysvětlování, že aktuální konsensus je, že v téhle situaci se BUG / BUG_ON() používat nemá, zatímco autor zarputile trval na tom, že jemu se to tak líbí.
A to je hodně velký rozdíl. Když mi bude maintainer tvrdit, že (obrazně) 2+2=3 nebo že určité řešení funguje (nebo naopak nefunguje) s v nějaké konkrétní situaci, a já budu objektivně vědět, že nemá pravdu, tak si samozřejmě budu stát za svým. Když mi ale napíše, že kolem výrazu použitého jako návratová hodnota nemám dávat závorky, že tady nemá být BUG_ON() nebo že nějakou část mám raději řešit jiným způsobem, to už jsou situace, kdy IMHO nemá smysl se dohadovat, pokud nemám v ruce podstatně silnější klacek než "ale mně to takhle připadá lepší".
A taky nemyslim, ze by bylo racionalni ocekavat, ze bych na LKML pristormoval s "delate to uplne napicu, tady je moje uzasne reseni(tm), ocekavam ho v pristim releasu".
To samozřejmě neočekávám. Ale z příspěvků v této diskusi i v dřívějších (memory management stojí za houby, cgroups stojí za houby, namespaces jsou k smíchu, ftrace je nepovedená napodobenina dtrace, BtrFS je nepovedená napodobenina ZFS, …) je IMHO dost zřejmé, že někde uvnitř ten pocit je. Koneckonců jste to napsal i přímo, že (v některých subsystémech) se podle vás jen flikuje a je potřeba, aby přišel někdo zvenku a celé to radikálně předělal. Je mi líto, ale já tam prostě tu nezbytnou míru pokory necítím.
A jakkoli neočekávám, že byste hned na začátku psal někco takového jako v citaci, nejsem si vůbec jistý, jestli máte dost sebeovládání, aby se ten pocit neprojevil nepřímo někdy později. Protože s netriviálním a radikálním patchsetem nevyhnutelně při review narazíte na místa, kde se s reviewery nebo maintainery neshodnete. Pak bude důležité, jestli někdy u v5 nebo v6 nepodlehnete pocitu, že se to zbytečně táhne, revieweři bazírují na ptákovinách, nechápou, jak je to skvělé a důležité, a nebo jsou dokonce proti vám nebo vašemu patchsetu zaujatí, a jestli vám vaše ego nezabrání udělat potřebné kompromisy.
Ještě víc mne děsí představa, že CoC je tu od toho, aby v podobných konfliktních situacích (z těch medializovaných mne napadá třeba ReiserFS, ReiserFS4 nebo kdbus, v menším pak třeba i zmíněný stackleak nebo aktuálně zinc) přispěchal deus ex machina a nehodnému maintainerovi rozbil… jeho bludné představy. (Oops, I did it again.) (and again :-) ) Kdyby to tak mělo být, nebude chtít maintainera dělat nikdo, kdo má jen trochu představu, co to obnáší.
ne primo tenhle CoC, ale tenhle smer povede k tomu, ze ty casti, co mi vadi, postupne prestanou smrdet … Brzdis nam to tu lidsky? Then you’re out a snajpa je happy a nema na co nadavat.
Děkuji, že jste mi pomohl nahlédnout marnost mého počínání. Kdybych byl škodolibý, těšil bych se na konfrontaci vašich představ o brave new world, kde "host vyhazuje vrchního", s realitou, ale vlastně je mi vás spíš líto.
To u mne respekt++ nezvzbuzuje.
Tak to mne ani v nejmenším netrápí.
4x, tak to pusobi fakt vtipne Neva.
Kdyz uz se tu bavime o kernelu - premyslim ted, jestli mne poslou do zadele s portem venet interface z OpenVZ na vanilla network namespace - pointa venetu oproti veth je, ze prenasi na L3 jenom povolene prefixy (original venet umi /32, /128, ja chci pridelat moznost libovolneho prefixu) - v tomhle pripade by to bylo z jednoho konce netns na druhy. Otazka je, jak se rozhodnout, jestli do te prace vubec jit - a pripadne si to valit pred sebou, kdyz nad to navalime zbytek vpsAdminOS stacku, aby venet znova pouzival (a nemusel pouzivat trapne obezlicky se spojovacimi subnety, kdyz chceme jet L3). I proto se na CoC chci divat jako na vec, co spis zveda sance na prijeti neceho, co tam "uz skoro je" (veth), "but not really" (resi totiz L2, kterou nepotrebujeme).
predevsim to uplne odstavi moznost spoofingu IP adres ze strany kontejneru
Spíš jsem myslel podrobnější popis celého toho setupu a požadavků, jak přesně se to má chovat.
je tam o mnoho kratsi codepath (jen L3)
Koncept L3 master device už nějakou dobu existuje a vrf a ipvlan jsou na něm postavené. Takže bych začal tím, jestli problém nelze vyřešit pomocí nich. Pokud ne, tak postavit vlastní implementaci na l3mdev.
Spolu s patchem pro zakazani conntracku pro root netns,
Proč je potřeba patch? Na tohle by mělo stačit jedno pravidlo v tabulce raw.
l3mdev by vypadal slibne, az na dve veci - mozna to ma reseni, nebo to jenom blbe chapu:
Userspace API As mentioned in the “Layer 3 Routing and Forwarding” section network addresses and routes are local to an L3 domain. Accordingly, userspace programs communicating over IPv4 and IPv6 need to specify which domain to use. If a device (L3 domain) is not specified, the default table is used for lookups and only addresses for interfaces not enslaved to an l3mdev device are considered.
Nas kontejner vlastne zadnou jinou routovaci tabulku nema; potreboval bych, aby ten interface byl v userspace "skoro k nerozeznani" od veth.
Driver venetu se mi docela libi a po posunuti nad novejsi kernel + netns misto openvz, by nemusel vypadat tak zanedbane, jak ted. Ale stejne, ta xmit path je proste turbo primocara...
Druha vec, netfilter hooky v recv i xmit path vypadaji nejak nebezpecne obkrocene, projde pres ne ten packet tak, aby clovek v danem netns mohl mit v pohode svoje iptables pravidla, jak je zvykly?
O raw tabulce jsem nevedel, patchovat conntrack na early bailout teda nebude treba, diky.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ip route add default dev venet0, na venet0 na hostu je pak privesena ta stejna /32 routa dev venet0. Nepotrebuje tak dve adresy, jak by to bylo v point-to-point pripade.
Will everybody be happy? No. People who don't like my blunt behaviour even when I'm not being actively nasty about it will just see that as 'look, nothing changed'. I'm trying to get rid of my outbursts, and be more polite about things, but technically wrong is still technically wrong, and I won't start accepting bad code just to make people feel better about themselves.
https://www.bbc.com/news/technology-45664640
/me happy, nic vic necekam. Lidsky pristupnejsi diskuzi o slozitych tematech, ne cca ...ty jsi debil snajpo, ze jsi odignoroval tadyten uplne jasnej use-case, kterej jsi zhorsil... a pak nasledny -> ... vy jste debilove, protoze nevidite, co vam rikam a musite mne trollit nadavanim mi do debilu... Hyperbolicky as always, ale snad je pointa videt uz ;)
Lidsky pristupnejsi diskuzi o slozitych tematech, ne cca ...ty jsi debil snajpo, ze jsi odignoroval tadyten uplne jasnej use-case, kterej jsi zhorsil...
Jenže takhle to nebylo a není. Nevím o případu, kdy by se někomu nadávalo za to, že udělal chybu, něco přehlédl nebo něco vyřešil způsobem, který je z nějakého (byť hodně známého) důvodu neakceptovatelný. Pokud jsem viděl nějaké skutečné urážky, pak šlo typicky o situaci, kdy maintainer nějakého subsystému (tedy ne nějaký náhodný kolemjdoucí, ale někdo, kdo by měl moc dobře vědat, co je přijatelné a co ne) takové nepřijatelné změny i po upozornění dál obhajoval.
Nakonec i ten nešťastný citát s křečkem, na kterém se pořád točíte, nebyl reakcí na to, že autor patchsetu použil BUG_ON() v situaci, kdy je to nepřijatelné, ale na to, že i po opakovaném upozornění trval na tom, že tam má být. Jistě, Linus mohl místo té citace jen suše konstatovat "Tohle je NACK a dokud to neopravíš, budu další verze automaticky ignorovat." Byl by to z praktického hlediska tak zásadní rozdíl? Pro mne moc ne. Patchset by v mainline stejně nebyl, dokud by ho autor neopravil. A [pd]okud by to neudělal, stejně bychom četli zhrzené komentáře, jak zlý Linus odmítá geniální patchset pod naprosto malichernými záminkami. Jen by v nich nebylo "a navíc je ještě hulvát".
Moje pointa je, že CoC a TAB tu nejsou a nemají být od toho, aby v takové situaci (lhostejno zda s křečkem nebo bez) donutily maintainera přijmout patchset, o kterém je přesvědčen, že je špatný (nebo dokonce maintainery odvolávat za to, že odmítnou). To bych považoval za opravdovou katastrofu. A jestli tu mají být jen od toho, aby řešily ty křečky, tak je mi líto, ale pořád nevidím ty zástupy geniálních vývojářů, kteří čekají jen na to, až bude LKML křečků prostý, aby mohli přinést svěží vítr a všechno od základu předělat.
Napr. Wireguard - jeste pred nejakou dobou by bylo nemyslitelne, aby tlacil nekdo VPNku do kerneluTo nevim, IPsec už je tam dlouho a virtuální interface pro IPSec tunel (vti) taky, takže mi to tak nemyslitelné nepřijde. A správci příslušných subsystémů jsou titíž lidé jako před nějakou dobou a nevšiml jsem si, že by měli něco proti wireguardu - ještě před CoC.
realne *je* ted ublizovano novym a je dokonce oslavovano nevhodne chovani.Není a není. To je celé jenom tvoje představa, kde ohýbáš realitu tak, aby to vyhovovalo tvému pohledu, že zatuchlost je způsobná něčím egem a ne tím, že se jedná o hodně složité problémy, které nelze řešit tím, co zrovna funguje pro vpsfree. Zrovna nedávno ti tady někdo ukázal, že ten úžasný ZFS algoritmus, který je podle tebe mnohem lepší než linuxová page cache, v jeho konkrétní zátěži padl na hubu. Pokud ti oškliví maintaineři blokují takové změny, plně je chápu - není přijatelné někomu způsobit regresi, protože někomu jinému server poběží líp. Btw. pokud jsi přesvědčen, že je novým ubližováno a že je dokonce oslavováno nevhodné chování, tak sem s příklady. Zejména to druhé by mě zajímalo.
Porad odmitate pochopit a videt, jak moc je core Linux timhl egoismem ovlivneny a prohnily, ale nepotrebuju “mit pravdu na Abicku”, mne bohate staci, kdyz nastane zmena k lepsimu v realu. Pokoru necitite a citit nebudete, dokud budete mit potrebu mne neustale moralizovat a napominat, jak jste si to zvykl. Jinou reakci od vas neznam, jen jen abyste mohl co nejhorliveji nesouhlasit a vsechno bagatelizovat.Jestli to nebude spíš tak, že jako aktivní přispěvatel do jádra má možná lepší vhled do fungování vývoje než ty. A že poukazuje na to, že tvoje představy člověka, který není aktivním přispěvatelem do vývoje jádra*, se neslučují s realitou? Jestli to bereš za napomínání, tak fajn. Ale tady se musím přidat, to co tu předvádíš, je přesně přístup zneuznaný génius, "všichni jste to doteď dělali blbě." Až pošleš nějaké patche a tohle předvedeš v LKML, tak tě fakt žádné CoC nezachrání a nikdo se s tebou nebude bavit. * mainline jádra, nemluvím o out-of-tree kódu
28.9.2018 14:24
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Zrovna nedávno ti tady někdo ukázal, že ten úžasný ZFS algoritmus, který je podle tebe mnohem lepší než linuxová page cache, v jeho konkrétní zátěži padl na hubu.No měl bych klidně další a to je necachování metadat. Dneska dělám cosi na stromu s 133tis soubory (cca 100GB), celý ten strom se prošel už asi 10x a každá další fáze (která začíná něčím jako
find . -type f -name něco) čte obsahy adresářů (neptám se na stats jednotlivých souborů) znovu. Dokonce i teď, když jsem pro tento komentář chtěl vědět počet (find . -type f | wc -l) to opět četlo celý strom z disku.
A to čtení metadat je teda výrazně pomalejší než na jiných FS. (Ale možná to dělá počet snapshotů, který u tohoto datasetu je aktuálně 248.)
Ale nestěžuju si. Ono to prostě běží, stejně to bude trvat do pondělí, procesy svoje data mají včas. Jen pocitově je toho čtení z disku prostě víc, než by muselo být.
https://bugzilla.redhat.com/show_bug.cgi?id=638477#c129 https://lkml.org/lkml/2012/7/6/495 http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01607.html => http://lkml.iu.edu/hypermail/linux/kernel/1804.0/01543.html http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html => ... http://lkml.iu.edu/hypermail/linux/kernel/1510.3/05223.htmlSorry, dal se mi ani vzpominat a googlit nechce, asi by mne zas presla chut si s tim jeho zazrakem vubec hrat...
Od ty doby, pokud vim, jsem nesundaval verejne ego nekoho, kdo se snazil prispet - kdyz nekdo navrhne kokotinu, nereknu mu: "jsi kokot", ale "navrhnul jsi kokotinu", kdyz uz jde fakt do tuhyho.
Tak tohle už je opravdu úsměvné. Přečetl jste si vůbec ty odkazy, kterými tu argumentujete?
I find your attitude to be annoying and downright stupid.
Magically changing kernel behavior depending on some subtle and often unintentional bootup behavior detail is completely idiotic. It would be idiotic if it was that "check kernel module signatures" check. This is no less idiotic.
The above code is sh*t, and it generates shit code.
I'm sorry, but we don't add idiotic new interfaces like this for idiotic new code like that.
Vynechal jsem reakci na Kaye Sieverse (protože Kay Sievers je hodně speciální případ) a dva odkazy z e-mailů, které vůbec nepocházejí od Linuse, u kterých netuším, proč v tom seznamu vlastně jsou (aby vypadal delší?).
A to už vůbec nemluvím o tom, na kolik tisíc Linusových mailů připadne jeden takovýhle. Vlastně bych se nedivil, kdyby u vás to procento (nebo spíš promile) nakonec bylo vyšší. Třeba jen máte štěstí, že u vás se každý takový výbuch hned nemedializuje a nerozebírá po fórech.
(Co uz je teda mega trapna vymluva, kterou si obhajuje byt zly na lidi, protoze on umi byt vylozene jedovaty, ne ze by si jenom delal srandu ze spatneho kodu...)
idiotskej navrh = navrhnul ho idiot
Nesouhlasím. Už jsem viděl spoustu (z mého pohledu) idiotských návrhů i od velmi inteligentních lidí, včetně takových, kterých si obecně vážím. Nakonec i mnohé své nápady s odstupem času hodnotím jako idiotské.
Ty dva linky byly na neco, kde by diskuze mela pokracovat, kdyby nebyl problem v osobnosti Linuse.Ne, neměla. Pokud Linus několikrát řekne, že v tichosti vypnout nějaké funkce jádra na základě toho, na čem se zrovna nabootovalo, je nepřípustné, a autor těch patchů stále tvrdí, že to tak být musí, tak diskuze nemá smysl, protože k ničemu nepovede. Mimo jiné si můžeš znovu všimnout, že to ani náhodou nejsou případy "navrhuju tohle" - "jsi debil", ze kterých máš takový strach. Naopak ta konverzace trvala delší dobu a do té doby slušně - a bylo to k ničemu, protože dokud to odmítnutí nebylo formulováno neslušně, tak se ta diskuze točila v kruhu. A jen tak mimochodem, zrovna tahle konverzace pak pokračovala a do jádra se to dostalo - v mnohem rozmnější formě. V tom druhém případě je to totéž - Linus řekl, že nechce v jádře vidět nepřehledný kód, když jde totéž udělat mnohem přehledněji a efektivněji. O čem by měla být další diskuze?
No, idiotskej navrh = navrhnul ho idiotNo ale v tom případě, když někomu řekneš, když už jde fakt do tuhýho, že "navrhl jsi kokotinu" místo "jsi kokot", tak jsi podle rovnosti výše vlastně řekl "jsi kokot". To mi přijde, že buď ta rovnost neplatí, nebo jsi stejný hluvát.
není moc lidí, co by se hrnuli do správcovských pozic A ZÁROVEŇ měli schopnosti to dělat dobře. Vykopnout lidi, co splňují obě tyto podmínky, na základě stupidního CoC, je buď nerealistické, nebo cesta do pekel.
Přesně tak. Jestli si někdo opravdu představuje, že to od teď bude fungovat tak, že kdykoli někdo přijde se svým geniálním patchsetem a bude mít problémy ho dostat do mainline, postěžuje si TAB (nebo kdo na to má dozírat) a TAB promptně maintainera "vykopne" nebo donutí patchset přijmout, tak buď trpí poruchou vnímání reality nebo je nebezpečný šílenec. Protože kdyby to takhle mělo opravdu fungovat
Samozřejmě existují situace, kdy maintainer funguje opravdu špatně, asi nejznámější příklad bylo SCSI, ale to, že někdo má problémy se svým patchsetem a často ho musí zásadně přepracovat, automaticky neznamená, že se jedná o ten případ. Velmi často je to spíš tak, že autor má před očima jen svůj use case, který se snaží vyřešit, zatímco maintainer musí vidět "the greater picture". Ano, je to frustrující a autor má často potřebu stěžovat si všude možně, často i s kohortou věrných fandů nadávajících na proradného maintainera, ale to problém nevyřeší. A už vůbec ho nevyřeší nějaký hypotetický orgán, který by v takovém případě automaticky ztrestal "drzého" maintainera.
Včera tu třeba padnul příklad stackleaku, tak jsem si našel příslušné diskuse. A možná proto, že nejsem zaujatý a netrpím představou, že každá forma hardeningu je automaticky dobrá a žádoucí, mkay, musím dát Linusovi v obou bodech za pravdu. Jak v tom, že tohle konkrétní řešení slouží spíš k přikrytí chyb než k jejich odhalení, tak v tom, že nasypat do kódu hromadu BUG_ON() chytajících chybové stavy, ze kterých se lze snadno zotavit, je principiálně špatně.
Představa je to nepochybně zajímavá, ale s hodnocením, nakolik se slučuje s realitou, bych raději počkal.
ze na nej sere a jeho mama je krecek
Facepalm… Co si takhle zjistit kontext a třeba i zkusit, co na tu větu řekne Google? Ale proč… ono je přece jednodušší takové nepochopení vydávat za důkaz, jaký je Linus strašný hulvát, který neumí odmítnout patch bez nadávek. Koho zajímá nějaká realita…
Jak rikam, co proste nepouzivat vubec formulace, ktery muzou bejt takhle explozivni?Problém je, že co je pro někoho úplně v pohodě, pro někoho jiného může být největší urážka, protože pochází z jiného kulturního prostředí, neviděl ten film, kteří viděli všichni ostatní atd. A co pak? Najmeme každému vývojáři jádra kulturního poradce? Nebo je donutíme k tomu, aby posílali naprosto odlidštěné maily?
jenom tvrdim, ze k cemu doslo je trochu neomalenej pokus vyslat signal, ze takovyhle vzbuzovani emoci v tak prerostlym projektu uz neni OKJá bych se spíš přiklonil k názoru, který už tady padl dřív - že ho k tomu začlenění CoC prostě někdo donutil.
Jak říká Rumcajs: "Však ono se ještě uvidí."
(Tak, a teď mi nezbývá než doufat, že jsem touto populárně kulturní referencí někoho neurazil. Případně že nebudu obviněn ze schvalování loupežnictví (což je nejspíš předchůdce terorismu) nebo tak něco.)