Javascriptová knihovna jQuery (Wikipedie) oslavila 20. narozeniny, John Resig ji představil v lednu 2006 na newyorském BarCampu. Při této příležitosti byla vydána nová major verze 4.0.0.
Singularity je rootkit ve formě jaderného modulu (Linux Kernel Module), s otevřeným zdrojovým kódem dostupným pod licencí MIT. Tento rootkit je určený pro moderní linuxová jádra 6.x a poskytuje své 'komplexní skryté funkce' prostřednictvím hookingu systémových volání pomocí ftrace. Pro nadšence je k dispozici podrobnější popis rootkitu na blogu autora, případně v článku na LWN.net. Projekt je zamýšlen jako pomůcka pro bezpečnostní experty a výzkumníky, takže instalujte pouze na vlastní nebezpečí a raději pouze do vlastních strojů 😉.
Iconify je seznam a galerie kolekcí vektorových open-source ikon, ke stažení je přes 275000 ikon z více jak dvou set sad. Tento rovněž open-source projekt dává vývojářům k dispozici i API pro snadnou integraci svobodných ikon do jejich projektů.
Dle plánu certifikační autorita Let's Encrypt nově vydává také certifikáty s šestidenní platností (160 hodin) s možností vystavit je na IP adresu.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 14.0 (Mastodon). Forgejo je fork Gitei.
Just the Browser je projekt, 'který vám pomůže v internetovém prohlížeči deaktivovat funkce umělé inteligence, telemetrii, sponzorovaný obsah, integraci produktů a další nepříjemnosti' (repozitář na GitHubu). Využívá k tomu skrytá nastavení ve webových prohlížečích, určená původně pro firmy a organizace ('enterprise policies'). Pod linuxem je skriptem pro automatickou úpravu nastavení prozatím podporován pouze prohlížeč Firefox.
Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
se mi zdá že je hned na začátku chyba ve verzi aktuálního jádra
Kde najdu anglický originál? Nikde ho nemůžu najít.
To OSD me desi. Je to cisty marketing, zadnou realnou vyhodu to podle me neprinasi. Zkratka, je to blbost.
I kdybychom pripustili, ze firmware bude otevreny, k cemu to podle vas bude dobre? Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility. Takhle si nainstaluji Linux a vim, ze vevnitr jadra je vsechno kompatibilni. S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atd. Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?
Bude to jen dalsi vrstva navic, ktera se bude muset konfigurovat, a ktera bude zdrojem nekompatibility.Jaký nekompatibility? To rozhraní je jasně stanovené a zdrojem nekompatibility bude akorát v případě, že výrobce standard poruší (akorát v takovém případě jeho zařízení dost pravděpodobně nebude fungovat dobře a lidi si ho nebudou kupovat.) A s konfigurací to pravděpodobně bude podobné jako u ostatních disků.
S OSD budeme resit, zda je dotycny firmware kompatibilni s prislusnou verzi operacniho systemu atdStandard je jeden, tak jaká kompatibilita s příslušnou verzí?
Jak pak asi ten disk prenesu nekam jinam, kdyz kazdy system bude pozadovat jiny firmware disku?To je jako kdybys řekl, že SCSI disk nemůžeš nikam přenést, protože systém bude požadovat jiný firmware disku.
> Standard je jeden, tak jaká kompatibilita s příslušnou verzí?
Dobry vtip. Viz treba ACPI. V okamziku, kdy je rozhrani dostatecne slozite, tak zajistit rozumnou kompatibilitu mezi nezavislymi produkty, zvlaste pak v asymtericke situaci, je dost problem.
Protoze jsou jednoduche a slozite veci. SATA ci SCSI v zakladni variante je relativne jednoduche (ve srovnani treba s ACPI), proto neni takovy problem, aby to fungovalo. Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu. Pripadne bude trvat leta, nez se vychytaji problemy.
Pokud je protokol jednoduchy a vsichni ho pouzivaji tim spravnym zpusobem, tak spis problemy nenastanou. Pokud je protokol bohaty a nabizi cetne moznosti, tim spis to fungovat nebude a bude treba resit kompatibilitu.Já osobně si myslím, že problémy vznikají jenom tam, kde vznik problému neznamená pokles obratu výrobce.
Vyhoda OSD by mohla byt v prenositelnosti dat mezi platformami. Mohla. Teoreticky.
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci). Pokud je uzavreny, jako treba u SCSI, tak moje namitka pada (ovsem soucasne nastupuji ty predtim).
Navic, jak rika Ondrej - SCSI je patrne pomerne jednoduche rozhrani ridici se cisly bloku. Tady maji byt nejake tokeny, sifrovani a ja nevim co jeste. Ten standard se bude vyvijet a menit, a nekompatibility tedy zakonite vzniknou.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?
Jenze ja mluvil o situaci, kdy bude ten firmware otevreny a kazdy si ho bude moci menit podle sveho (coz jste predtim povazoval za zadouci).Tak pozor - otevřený firmware, který si každý bude moci měnit podle svého, a dodržení protokolu jsou dvě různě věci. Pokud to převedu na současnou situaci, tak protokol je, že programy volají funkce jako je
open(), fread() a je jim jedno, jak to vypadá pod nimi, jestli jádro naváže síťové spojení s NFS serverem nebo začne číst z diskety. Implementace ext3 se může třikrát změnit, ale programu to bude jedno, protože open() stále bude otevírat soubor.
Stejně tak u OSD se může firmware měnit tím způsobem, že se například změní rozložení bloků souborů na disku, protože se ukáže, že novější varianta je efektivnější. V podstatě se může změnit cokoliv, co se v současných jádrech mění u souborových systémů. Podstatné je, že navenek ten firmware na požadavek na čtení souboru číslo 12345 vždy odpoví čtením souboru číslo 12345.
A jeste jste mi neodpovedel na otazku, v cem vlastne spatrujete vyhody OSD?Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Ale do RAIDu už to asi nedám.
Myslím, že výhodné to může být u malých zařízení, jako jsou MP3playery či fotoaparáty, protože nebude třeba implementovat FS driver. Ale u osobních počítačů to moc určitě úspor výkonu nepřinese, ale přinese to určitě problémy s RAID a kompatibilitou a variabilitou.
Návrh existuje právě proto, aby vyšší výkon přinesl. Dnešní operační systém vůbec netuší, kde jsou sektory fyzicky uloženy, takže nedokáže dělat vůbec žádné optimalizace s výjimkou jediné: "Sektory bezprostředně za sebou = rychlejší operace". Naproti tomu OSD by byl fyzicky vázán k disku a znal by jeho strukturu. To může přinést významný nárůst výkonu jak u rotujících, tak u flash disků.
A co víc: ESD by mohl měnit fyzickou strukturu dat v závislosti na typu zapisovaných dat. Například při zapisu video streamu by mohl nepřerušeně zapisovat do sektorů o délce celé stopy, při práci s fragmentovanými daty by je dokázal efektivněji uložit pro náhodný přístup.
RAID by s ESD zcela změnil implementaci. Zatímco dnes se ukládají sektory a kontrolní bloky, ESD RAID řadič by distribuoval objekty nebo kontrolní objekty, zatímco na vstupu by přijímal ESD objekty od OS.
To bych stále považoval za lepší, kdyby zařízení o sobě umělo říct první poslední, než tohle.
To by vyžadovalo mnohem vyšší komplexitu OS. Zde jsou příklady z možných vstupů pro optimalizaci:
Nyní si představte, že nový fiktivní standard DiskDescription verze 1.0 vytvoří infrastrukturu, která to vše zvládne. Pak přijde další výrobce, který nabídne disk s nezávislým vystavováním hlaviček na plotnách, se dvěma hlavičkami nebo s možností paralelního čtení ze všech ploten, nebo třeba hybridní disk, který má nejčastěji čtená data ve flash paměti. DiskDescription verze 1.0 k popisu nebude stačit, a k podpoře nového zařízení bude potřeba aktualizovat všechny OS na DiskDescription verze 1.1, nebo se vrátit k neefektivnímu nepřůhlednému LBA režimu.
Pokud chcete mit jednoduchy OS, tak proste pouzijete cisla bloku a na rychlosti se vykaslete. Pokud chcete mit rychly pristup na disk optimalizovany podle organizace disku, pak dejte OS vsechny informace, a ten uz si to zaridi. Ale firmware disku neni od toho, aby resil specificke potreby jednotlivych aplikaci - od toho je OS, ktery se da snadno zmenit.
Naopak firmware ma resit specificky system rozlozeni na disku, a poskytovat rozhrani, ktere je co mozna nejrychlejsi a pritom jednoduche. Coz cisla bloku splnuji docela dobre (proto jsme na ne take presli od cylindru/sektoru/hlav, vzpominate?).
Vas priklad je zavadejici. Pokud se napriklad ve vasi aplikaci nespokojite s tim, ze za sebou jdouci bloky mohou skoncit na ruznych cylindrech (a budete chtit za sebou jdouci bloky s co mozna nejrychlejsim pristupem), budete muset zacit fyzickou vrstvu resit pres nejake vhodne rozhrani. Neni jina moznost. Ale OSD takove rozhrani neni - z toho, co jsem videl na tech strankach, mi nepripada, ze by v takovem pripade nejak pomohlo. Naopak se spis snazi delat veci, ktere by mel delat OS (jako sifrovani, partitioning, metadata).
„Všechny informace o hardwaru“ je velmi povrchní pojem. Aby to fungovalo, musela by existovat rozsáhlá a komplexní norma, která by popisovala vlastnosti všech představitelných zařízení pro ukládání dat, a stejně komplikovaná implementace v OS. A přesto by se časem objevilo zařízení, na jehož popis nestačí.
Systém cylindrů/sektorů/hlav byl kdysi lepši než LBA. K systému LBA v kombinaci s falešnými cylindry/sektory/hlavami se přešlo kvůli omezením MS-DOSu. Systém, kdy OS a sběrnice používají LBA, HDD vnitřně používá fyzické sektory (nerovnoměrně rozmístěné po disku), a BIOS a tabulka partition používá (na BIOSu základní desky závislý) systém falešných rovnoměrně rozmístěných cylindrů/sektorů/hlav není ani rychlý, ani přímočarý. Oddíl tak třeba fyzicky začíná uprostřed stopy a nejrychleji se čte spolu s koncem předchozího oddílu.
Již dnes prostý systém LBA přestává stačit. Například nesmírně komplikuje implementaci zápisových bariér. Vysoce bezpečný FS musí zapsat žurnál, poté metadata a data, a nakonec vymazat žurnál. Fyzický zápis na plotny musí být proveden přesně v tomto pořadí, nestačí pouze odeslání do vyrovnávací paměti HDD. Často je jedinou cestou čekání na kompletní vyprázdnění vnitřni vyrovnávací paměti HDD, kdykoliv OS narazí na bariéru.
Přesun metadat do nižší vrstvy je logický krok. Hardware má k dispozici více informací o povaze zapisovaných dat (velké bloky, malé bloky, metadata) a může provádět daleko lepší optimalizaci.
Při dobré implementaci to znamená snížení zátěže hostitelského systému. V podstatě by šlo o akcelerátor diskových operací, kdy by se jádro nemuselo zabývat rozložením souborů na disku tak, jak to dělá dnes. Když se to vezme kolem a kolem, tak jednoduchá implementace by mohla být taková, že by na tom disku v podstatě klidně mohl být nějaký současný Linux - ten by se staral o ukládání dat třeba na ext4 a hostitelskému systému by poskytoval rozhraní OSD disku.
Akcelerator ma smysl tam, kde je jasne, ze problemu napomuze jine hardwarove usporadani nez pouzivaji soucasne procesory (tj. napriklad u grafiky, kde se pouzivaji vektorove/stream procesory, nebo u sifrovani apod.). V ostatnich pripadech je uzitecnejsi proste pridat dalsi obecny procesor, protoze softwarove reseni je nejenom praktictejsi, ale muzete ten procesor vyuzit i pro jine ucely nez I/O.
Je pravda, že ten procesor tam asi bude dost stejný, nicméně možná by se dalo právě tím že se dá jinam odlehčit některým sběrnicím, které jsou nyní úzkým hrdlem mnohem více než rychlost a množství procesorů. Ale spíš to asi nemá smysl.
Co ty no-opy ? To mam chapat jako instrukci NOP ?
mov r0, r0, či niečo podobné).
Tiskni
Sdílej: