Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
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.
Aktuální vývojová verze je nadále 3.6-rc1; Linus další předverzi nevydal, protože byl od 2. srpna na dovolené. Do repozitáře se ale postupně dostávají opravy; další verze by měla vyjít brzy.
Stabilní aktualizace: verze 3.0.40, 3.4.8 a 3.5.1 vyšly 9. srpna; verze 3.2.27 vyšla 11. srpna; a verze 3.0.41, 3.4.9 a 3.5.2 vyšly 15. srpna. Poslední zmiňovaná skupina obsahovala kromě běžných oprav i vylepšení v generátoru náhodných čísel.
Snažím se předstírat, že jsem neschopný správce, aby se někdo nabídl, že to po mě převezme. Zatím to nevyšlo.
-- Neil Brown
Nuže, tohle byla má snaha strávit několik dnů nad něčím pohodovějším než secure boot. Skončilo to ekzémem a bolestí jater. Plyne z toho pro mě ponaučení, že výrobci hardwaru vás nenávidí ještě víc než výrobci firmwaru.
Pracovní fronty jsou hlavním nástrojem pro odklad úloh v linuxovém jádře. Správcem této funkčnosti je Tejun Heo, který nedávno zaslal sadu patchů měnící vlastnost pracovních front, o které ví asi jen málo jaderných vývojářů. Většina pracovních front je reentrantní, což znamená, že stejná položka ve frontě může běžet na více CPU současně. To může vést k souběhu, jenž nemusí vývojáři očekávat; taktéž to zajímavým způsobem dosti komplikuje různé „flush“ operace. Tejun to shrnuje slovy:
Pracovní fronty jsou ve výsledku dost nepříjemné, je obtížné udělat věci správně a stejně tak obtížné je postřehnout, že se něco rozbilo. Podle situace, jak se úlohy zrovna řadí do fronty, může předpoklad, že fronta není reentrantní, být po většinu času v pořádku. Dopad používání flush_work() namísto správného flush_work_sync() může být ještě méně nápadný. To, že by se flush_work() stalo nulovou operací, se stane jen naprosto výjimečně, ale určitě to hrozí.
Nástroj, které je tak intenzivně používán, jako jsou pracovní fronty, by neměl být tak složitý a náchylný na chyby. To je prostě hloupé.
Tejunův patch má za cíl změnit rozhraní front tak, aby se chovalo více jako rozhraní časovače, které je v souběhu opatrnější. Zjevně to má za následek drobné snížení výkonu, ale Tejun je označuje za zanedbatelné a měly by se urychlit operace flush. Vypadá to, že to za to stojí, ale všichni, kteří udržují kód závisející na souběžném spouštění úloh ve frontě, by měli být na pozoru.
Jednou z mnoha výhod síťového protokolu TCP je to, že procesy na obou stranách nemusejí mít tušení, kde se druhá strana nachází. Proces může komunikovat s procesem na druhé straně světa, ve stejném městě nebo samozřejmě na stejném stroji. Poslední situace nemusí být relevantní pro zmiňované procesy, ale může být důležitá pro uživatele citlivé na výkon. Nový patch od Google tuto situaci v brzké době zrychlí.
Buffer dat zaslaný sítí necestuje sám. Vrstva TCP musí buffer rozdělit do rozumně velkých paketů, připojit sadu hlaviček TCP a pravděpodobně i spočítat kontrolní součet. Pakety jsou pak předány vrstvě IP, která přidá vlastní hlavičky na začátek bufferu, najde vhodné síťové rozhraní a předá výsledek tomuto rozhraní k odeslání. Na druhé straně tento proces probíhá opačně: hlavičky IP a TCP jsou odstraněny, kontrolní součty jsou porovnány a data jsou sloučena do souvislého proudu.
Jde o docela dost práce, ale umožňuje to dvěma procesům komunikovat nezávisle na tom, co se děje mezi nimi. Ale pokud jsou oba procesy na stejném stroji, většina této práce není skutečně nutná. Většina režie v síťové vrstvě souvisí se snahou zabránit ztrátě dat po cestě. Toto nehrozí v případě, že data systém vůbec neopouštějí, takže spousta práce síťové vrstvy je zcela zbytečná.
To vývojáři vědí už celé roky. Proto tolik programů umí používat unixové sokety při komunikaci s místními procesy. Unixové sokety poskytují stejnou úroveň abstrakce, ale protože nekomunikují mezi systémy, vyhnou se tak režii přidávané plným síťovým stackem. Rychlá komunikace mezi procesy tedy možná je, ale musí se s ní počítat explicitně.
Co kdyby komunikaci přes TCP bylo možné zrychlit tak, aby byla srovnatelná s unixovými sokety? To je cílem tohoto patche od Bruce Curtise. Myšlenka je prostá: když jsou oba konce spojení na stejném stroji, sokety jsou v jádře označeny jako „spřátelené“. Data zapsaná do takového soketu budou okamžitě zařazena pro čtení na druhém soketu, takže se síťové vrstvě vyhnou. Vrstvy TCP, IP a loopback se tím obejdou. Samotný patch je pak pochopitelně trochu složitější než co by dal tušit samotný popis; spřátelené sokety se musejí nadále chovat jako TCP sokety do míry, aby aplikace nic nepoznaly, takže ošetřování přátel musí být řešeno na mnoha místech ve vrstvě TCP.
Člověk by doufal, že výsledkem budou rychlosti alespoň blízké unixovým soketům. Brucův patch toho nejen dosahuje, ale unixové sokety dokonce předčil v téměř všech testech. „Předčil“ znamená vyšší rychlost přenosu i nižší latenci. Bruce už nerozebírá, jak je to možné; třeba za to může úsilí vložené do škálovatelnosti síťové vrstvy ve spojení se 16jádrovým systémem.
Zbývá jeden test, který Bruce nedělal: nezpomaluje náhodou jeho patch komunikaci se vzdálenými stroji, kde není obcházení síťových vrstev možné? Některá vytěžovaná místa mohou být citlivá i na ty nejmenší změny, takže se dá čekat, že vývojáři budou chtít ujištění, že vzdálená spojení neutrpí. Zbývají ještě další drobné problémy, jež je nutné vyřešit, ale vypadá to, že se patch dostane do jádra v brzké budoucnosti.
Po začlenění by výsledkem byla rychlejší lokální komunikace mezi procesy bez nutnosti dodatečného kódu pro unixové sokety. Mohlo by se to hodit i k rychlejší komunikaci mezi kontejnery; dá se odhadovat, že tak nějak je to používané i v Google. Tak jako tak je těžké bojovat proti patchi, který dokáže až pětinásobně urychlit lokální komunikaci, tudíž je pravděpodobné, že se patch dostane do jádra velmi brzy.
Mnoho zařízení nedokáže fungovat, dokud do nich systém nenačte ten správný firmware. Firmware načítaný za běhu má své výhody: hardware může být levnější vyrobit a firmware je možné snadno aktualizovat i po prodeji výrobku. Představuje to ale i problémy, zejména ve spojení s jinými funkcemi. Správné načítání firmwaru při cyklech suspend/resume představovalo pro jádro už nějakou dobu velkou výzvu, nová sada patchů by to ale měla zlepšit bez potřeby změn v ovladačích.
Problémem je zjevně to, že kterékoliv zařízení může během uspání ztratit svůj firmware. Smyslem uspávání systému je snížení spotřeby na minimum, takže některé periferie se mohou vypnout úplně. Ztráta firmwaru při uspání nevypadá jako velký problém; ovladač přece může firmware při probouzení systému načíst znovu. Jenže firmware se nachází na disku a k jeho načítání je nutné spustit pomocný proces v uživatelském prostoru. Disk a uživatelský prostor nemusejí být v době, kdy si zařízení vyžádá firmware, dostupné; ovladače, které se o to pokusí, mohou škaredě selhat. Výsledkem jsou pak selhání probuzení systému; mohou být náhodná, takže na ně vývojář nikdy nenarazí a nikdy je ani nevystopuje. Proto se už nějakou dobu hledá robustnější řešení.
Ming Lei se v červenci pokusil tento problém vyřešit patchem, který integruje načítání firmwaru do mechanismu odloženého zkoušení ovladačů. Zjednodušeně jde o to, že pokud načtení firmwaru selže, tak je celá inicializace ovladače odložena do fronty, odkud je pak pokus opakován. Tudíž pokud ovladač nebude schopen načíst svůj firmware během probouzení, zkusí se to později znovu a tehdy už snad budou potřebné prostředky dostupné. Ming doufal, že to vyřeší mnoho selhání probuzení bez potřeby měnit spousty ovladačů.
Linus ale nesouhlasil:
U spousty zařízení nevadí načíst firmware později. Některá ale mohou být kritickou součástí sekvence probuzení systému a odložení načtení firmwaru tak bude jen znamenat selhání probuzení.
Podobný způsob odložení načtení firmwaru by dle jeho názoru ukryl problémy před vývojáři a poprali by se pak s nimi uživatelé. Je prý mnohem lepší donutit autory ovladačů řešit problém explicitně.
Tradičním způsobem řešení problému je udržovat firmware v paměti po jeho načtení. Trvale načtený firmware bude vždy k dispozici, takže opětovné nahrávání by mělo být robustní. Problémem je, že některý firmware může být dosti velký; trvalé udržování by plýtvalo jadernou pamětí. A je to ještě horší, bloby jsou načítané do paměti vmalloc() (aby byly v paměti souvislé); této paměti může být na 32bitových systémech málo. Trvalé cachování tedy není ideálním řešením, ale tak to hodně ovladačů teď dělá.
Po debatě s Linusem se Ming na chvíli zamyslel a přišel s novým návrhem: firmware cachovat, ale jen během cyklu suspend/resume. Ovladače to samozřejmě mohou takto dělat už teď. Ale jde o spoustu opakujícího se kódu, který by bylo nutné přidat do každého ovladače. Mingův patch tyto kroky automatizuje a zjednodušuje.
request_firmware() je konkrétně změněno tak, aby si zapamatovalo název každého načítaného blobu. K tomuto je uložen počet referencí a údaj o tom, která zařízení firmware potřebovala; při odpojení pak tedy celý záznam může být odstraněn. Výsledkem je jednoduchá datová struktura sledující všechny bloby, které mohou být požadovány hardwarem, jež je v systému aktuálně přítomen.
Při uspávání pak kód jednoduše načte všechen firmware, o kterém věří, že může být potřeba. Tato data následně zůstávají v paměti během uspání. Při probouzení systému jsou takto nacachované bloby dostupné ovladačům bez potřeby přístupu k souborovému systému nebo uživatelskému prostoru přes obvyklé rozhraní request_firmware(). Jakmile je proces probuzení dokončen, načítač firmware veškeré obrazy firmwaru uvolní.
Patch má zdá se k ideálnímu řešení blízko. Načítání firmwaru při probouzení se stane robustnějším, ovladače se o princip fungování nemusejí starat a promrhané paměti je minimum. I Linus poznamenal Nic mě na tom patchi nezhnusilo, což je od něj docela vysoké ocenění. Neřeší to ale každý problém; kupříkladu pak existují podivná zařízení, která si firmware uchovají během restartu, ale už ne během uspání, takže systém nemusí o potřebě firmwaru tušit a pak už je pozdě. Takový hardware je ale asi lepší řešit odděleně jako speciální případ. Pro zbytek se blížíme řešení, které prostě funguje – a tím se přibližujeme ke konci věčných debat na téma „firmware po probuzení“.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
For example, maybe it's a USB network dongle, and for *YOU* it is perfectly fine to defer the firmware loading, so that the network comes back up a few seconds after the system is up and running. But in another machine, that exact same USB network dongle may actually be hardwired on the motherboard (it's fairly common to use USB as a "system bus" in some laptop and embedded devices), and maybe that other machine actually is a thin client that has some tiny rdinit thing, and then everything else is NFS-mounted, and if you resume without networking, the machine is simply *dead*.Pokud má tenkej klient nějaký úložný místo odkud bootuje z rdinit, tak tam musí mít i firmware, aby mohl připojit NFS ne? V nejhorším případě je ten firmware v BIOSu, ale aspoň je furt dostupnej.
Data zapsaná do takového soketu budou okamžitě zařazena pro čtení na druhém soketu, takže se síťové vrstvě vyhnou.A co iptables pravidla, která by se měla aplikovat? Pokud potřebuji přímé spojení, tak přece použiji unixové sockety -- a to má i jiné výhody (řízení přístupu podle uživatelů). Tu abstrakci by měla řešit spíš nějaká knihovna/framework v aplikaci, než že by OS měl dělat takovéhle hacky, podstrkávat nějaké přímé spojení a tvářit se, že je to TCP.
A co iptables pravidla, která by se měla aplikovat? Pokud potřebuji přímé spojení, tak přece použiji unixové socketyTaky se divím, proč se řeší věc, která už je vyřešená, ale budiž, nejspíš to bude nějaká specifická potřeba Googlu.
On vetsinou spravce predpoklada, ze pokud neco komunikuje po siti, tak to komunikuje po siti a ne nejakou dirou nekde cestou.Oni jsou ti správci vůbec často překvapení, co se to v jejich sítích děje. A to kolikrát i když si to sami nakonfigurovali. Ale souhlasím s tebou a je mi osobně proti srsti jim v tom dělat ještě větší bordel, než je nutné. Až budu testovat aplikaci na localhostu a sledovat si ji tcpdumpem a ten tcpdump mi bude ty pakety zatajovat, tak se mi to nebude líbít. Už teď musí člověk lokální komunikaci hledat na rozhraní lo místo rozhraní, na kterém je daná IP nastavená.
Už teď musí člověk lokální komunikaci hledat na rozhraní lo místo rozhraní, na kterém je daná IP nastavená.To je ovsem perfektne konzistentni s chovanim IP komunikacie v Linuxu obecne - pokud napr. prichazi komunikace na eth0, ale je cilena na IP z eth1, tak ji na eth1 take tcpdumpem nezachytim. Ono na Linuxu je to prirazeni IP rozhranim relativne volna a neprilis dulezita vazba, napr. na ARP ti odpovida bez ohledu na to, na kterem to rozhrani ta adresa je.
To je ovsem perfektne konzistentni s chovanim IP komunikacie v Linuxu obecneTo vůbec nerozporuju :).
napr. na ARP ti odpovida bez ohledu na toMně lokální stroj na ARP neodpovídá nikdy. Vzdálený stroj mi správně na ARP odpovídá pouze pokud použiju jeho adresu na rozhraní, po kterém ten ARP dostane.
Vzdálený stroj mi správně na ARP odpovídá pouze pokud použiju jeho adresu na rozhraní, po kterém ten ARP dostane.Tak to ho mas prenastaven nebo prislusne zafirewallovan. Defaultni chovani je takove, jake pisu.
On vetsinou spravce predpoklada, ze pokud neco komunikuje po siti, tak to komunikuje po siti a ne nejakou dirou nekde cestou.Správca má vedieť, nie predpokladať. Správca, ktorý mal už pod rukami taký Solaris, nič také predpokladať nebude. Tam totiž localhost odjakživa funguje predávaním údajov v pamäti.
To je ale dost odlisny pripad. Zatimco u fd sice programator pouziva stejne funkce, tak ale typicky vi a pocita s tim, ze pouziva fd nejake 'tridy' a pulka operaci je specificka ci se chova lehce jinak pro jednotlive 'tridy'Zajímalo, jak se pozná ta specifická půlka operací v době, kdy už jsem připojený (či je někdo ke mě připojený) pomocí TCP nebo pomocí UNIX/STREAM. V tu dobu používám read/write (mohl bych používat send/recv) a časem asi budu chtít použít close. To celé doprovází poll u asynchronního přístupu. Víc mě nic nenapadá.
takze by abstraktni vrstva klidne vymenila pri lokalni komunikaci TCP za unix socket a program by si toho nevsimlCož dělá víceméně ten kernel patch. Vymění TCP protokol za jednodušší způsob lokálního předávání dat po vzoru AF_LOCAL.
Což dělá víceméně ten kernel patch. Vymění TCP protokol za jednodušší způsob lokálního předávání dat po vzoru AF_LOCAL.Jenze ten patch taky (hadam) zajistuje, aby se pro vsechny ty 'trida-dependent' operace stale choval jako TCP. Zatimco u nejake typicke genericke abstrakce kdybych chtel precist cislo portu ze socketu, ktery je vlastne implementovan unix socketem, tak by to selhalo.
Tak treba ve funkcich pracujicich s adresami (getsockname(), getpeername()), ty se obcas pouzivaji pote, co se na listening socket nekdo pripoji.Proto jsou adresy polymorfní.
Pak spousta socket options nastavovanych pres setsockopt(), s pouzivanych treba TCP_CORK, IP_TOS, IP_TTL.Ještě jsem nepotřeboval nastavovat volby jindy než během inicializace.
Jenze ten patch taky (hadam) zajistuje, aby se pro vsechny ty 'trida-dependent' operace stale choval jako TCP.Pokud používám přímo socketové rozhraní a jeho úroveň abstrakce, tak někde v kódu volám
socket()
, kde určuju, jaký typ socketu to bude. V návaznosti
na to lze vyřešit všechny specifické věci. Na straně serveru to bude accept()
.
Zatimco u nejake typicke genericke abstrakce kdybych chtel precist cislo portu ze socketu, ktery je vlastne implementovan unix socketem, tak by to selhalo.U generické abstrakce je nesmysl číst číslo portu. Stejně tak u polymorfního socket API nemá smysl chtít číslo portu od AF_LOCAL.
Proto jsou adresy polymorfní.Jo, jenze v konecnem dusledku tu adresu stejne budes chtit nejak zpracovat a tam uz jde polymorfnost stranou (nehlede na to, ze pro ni predem musis vyhradit dost pameti).
U generické abstrakce je nesmysl číst číslo portu. Stejně tak u polymorfního socket API nemá smysl chtít číslo portu od AF_LOCAL.Pokud by ta abstrakce byla 'natolik' polymorfni, aby podstrcila UNIX socket tam, kde programator zadal TCP, jen na zaklade toho, ze IP adresa cile je lokalni (jak IMHO pozadoval puvodni prispevek), tak by mysela byt natolik transparentni i v ostatnim 'trida-dependent' chovani.
Jo, jenze v konecnem dusledku tu adresu stejne budes chtit nejak zpracovat a tam uz jde polymorfnost stranouTam přesně využiju polymorfie, která mi mimojiné nabízí možnost větvit kód podle konkrétního podtypu.
Pokud by ta abstrakce byla 'natolik' polymorfni, aby podstrcila UNIX socket tam, kde programator zadal TCPTaková abstrakce mi přijde na první pohled chybná. Správná abstrakce je taková, která dokumentované rozhraní implementuje. V tomto případě musíš buď změnit abstrakci, aby si poradila se všemi specifiky TCP (což se skoro určitě lépe udělá v kernelu a což dělá zmíněný patch), nebo musíš změnit dokumentaci, tedy poskytované API a nevydávat AF_UNIX za AF_INET*, ale udělat smysluplnou abstrakci nad nimi, která bude zahrnovat i další operace, ve kterých se tyto rodiny liší (například to ověření jména uživatele).
Pak spousta socket options nastavovanych pres setsockopt(), s pouzivanych treba TCP_CORK, IP_TOS, IP_TTL.Ještě jsem nepotřeboval nastavovat volby jindy než během inicializace.
Zrovna TCP_CORK
je option, kterou dost dobře nelze nastavit jen při inicializaci. U IP_TOS
nebo TCP_NODELAY
jsou také situace, kdy by mělo smysl měnit hodnoty podle toho, jak se mění charakter komunikace (třeba u SMTP).
Na druhou stranu, pokud aplikace počítá s tím, že může používat jak PF_INET
/PF_INET6
sockety, tak PF_UNIX
, může samozřejmě nastavovat jen ty socket options, které mají pro daný typ socketu smysl.
Predstava takove abstrakce me prijde dost absurdni.Přitom už to někde viděl. Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.
nebo by to proste emulovalo TCP pomoci UNIX socketuNěco podobného dělá patch, který tuto debatu rozvířil.
Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.Kde se neco takoveho realne dela?
Něco podobného dělá patch, který tuto debatu rozvířilAle zpusobem, ktere je pro programy daleko transparentnejsi.
Kde se neco takoveho realne dela?Tohle dělá/dělal nějaký klient k MySQL, ale asi by se našlo víc příkladů. Pomohlo napsat
127.0.0.1
místo localhost
.
Ale zpusobem, ktere je pro programy daleko transparentnejsi.To jistě.
Kde se neco takoveho realne dela?MySQL knihovna k PHP
Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.Což není abstrakce, ale spíš šamanismus – takové aplikace mám opravdu rád. Např. když si člověk pracně protuneluje nějaký vzdálený port na localhost, chce se připojit, nejde to… a po chvíli zjistí, že aplikace si chytře vyložila localhost tak, že se má připojit na UNIXový soket na nějakém obvyklém místě v adresářové struktuře.
Dělá a z principu je to úplně zcestné. Buď potřebuji jen vstupní a výstupní proud a pak mi dostatečnou abstrakci poskytuje stávající API* nebo potřebuji specifické** vlastnosti dané technologie a pak použiji ji – nemá cenu maskovat jednu technologii za jinou a klamat uživatele. Optimalizace ano, ale nesmí nic rozbít ani se chovat podivně a nečekaně. *) samozřejmě, že spojení se bude vytvářet vždycky trošku jinak – i když i tohle jde zobecnit, schovat za nějakou obalovou vrstvu, které předám URL a dostanu I/O proudy, takže se budou spojení dokonce i vytvářet stejným způsobem. **) např. vědět, který uživatel se připojuje k unixovému soketu a mít možnost řídit práva stejně jako u souborů, nebo mít třeba síťovou transparentnost a možnost používání iptables pravidel.nebo by to proste emulovalo TCP pomoci UNIX socketuNěco podobného dělá patch, který tuto debatu rozvířil.
Což není abstrakce, ale spíš šamanismus – takové aplikace mám opravdu rád.Je fakt, že mělo být použito něco neobsazeného, třeba NULL nebo prázdný řetězec. Taky o tom vím jen díky tomu, že mi to za nějakých okolností nefungovalo, stejně jako ty.
Dělá a z principu je to úplně zcestné. Buď potřebuji jen vstupní a výstupní proud a pak mi dostatečnou abstrakci poskytuje stávající API* nebo potřebuji specifické** vlastnosti dané technologie a pak použiji ji – nemá cenu maskovat jednu technologii za jinou a klamat uživatele.Taky mám dojem, že TCP bypass je spíše kontraproduktivní technika, která ve skutečnosti neřeší chybějící funcionalitu kernelu, ale neschopnost nějaké googlí bezpečnostní služby, která je schopná pracovat pouze s AF_INET* a ne AF_LOCAL. Ale to je jen můj odhad, nic o tom nevím.
A co iptables pravidla, která by se měla aplikovat?
Pravidla netfilteru, queueing disciplines nebo síťové statistiky to obejde. Proto bych asi byl raději, kdyby to defaultně bylo vypnuté a zapnul si to jen ten, kdo bude chtít vyšší výkon lokálních TCP spojení za cenu toho, že některé funkce (které ale v takové situaci stejně nejspíš nebude využívat) nebudou správně fungovat. V upstreamu to zatím vypadá spíš na defaultně zapnuté (ten patch není ještě ani v net-next a poslední submitnutá verze byla s aktuálním jádrem dost rozbitá a všechny benchmarky a testy byly dělané na starších), uvidíme, co na to distribuce.
než že by OS měl dělat takovéhle hacky, podstrkávat nějaké přímé spojení a tvářit se, že je to TCP
"Takových hacků" jsou už teď spousty, např. veškeré *-offloading funkce nebo to, že se na lokální smyčce nepočítají checksumy v IP hlavičce (možná i TCP, to si z hlavy nepamatuji).
Proto bych asi byl raději, kdyby to defaultně bylo vypnuté a zapnul si to jen ten, kdo bude chtít vyšší výkon lokálních TCP spojení za cenu toho, že některé funkce (které ale v takové situaci stejně nejspíš nebude využívat) nebudou správně fungovat.+1