Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Bývaly doby, kdy základním deskám drtivě dominovaly integrované síťové čipy společnosti Realtek. Postupem času se ale stále více objevují různá vyšší řešení s vyšší kvalitou běhu. Ať už jde o různé Broadcommy nebo přímo čipy od Intelu nebo naopak přebubřelé a marketingem protkané síťovky Killer, postavené na ARM jádru od Qualcommu, Realteků na základních deskách zkrátka ubývá. Výrobci základních desek totiž, jak se toho stále více přesouvá do CPU či čipsetu, mají stále méně prostoru se od sebe vzájemně odlišit, nabídnout zákazníkovi nějakou tu pověstnou třešničku na dortu, která jeho rozhodování přiohne k dané značce.
A tak jako se zvukovými čipy, kdy mnoho výrobců dnes volí jak lepší čipy (třeba od Creative), tak lepší DAC či fyzické oddělení a odstínění zvukovky od zbytku základní desky a přidání sluchátkového zesilovače, tak nahrazují i „generický“ Realtek GLAN něčím jiným. MSI třeba volí často právě Killer, ale velmi často vídáme Intel (i na deskách platformy AMD) či Broadcomm. Realtek na to musel nějak reagovat.
Výsledkem vývoje a snahy zvrátit nepříznivý stav, je čip Realtek Dragon RTL8118AS, tedy PCI Express GLAN PHY, které výrazně oproti stálici RTL8111 vylepšuje zejména práci s velkým množstvím UDP paketů, což je věc klíčová mimo jiné pro online hraní. Přináší také nižší spotřebu jak oproti dřívějším čipům, tak oproti současné konkurenci. Uvidíme jak si povede, objevit se má prvně na základních deskách od ECS pro platformu LGA1151 / Skylake.
Sotva jsme se dozvěděli, že Cannonlake se zpozdí a jeho místo na slunci po jistou dobu zastoupí „Skylake Refresh“ zvaný Kabylake, přichází další smutná zpráva: i Kabylake se o něco opozdí. Původně se hovořilo již o začátku roku 2016, nově se má Kabylake objevit až na podzim 2016.
Ono to ale dává smysl, protože první odemčená čtyřjádra Skylake pro desktopy se mají objevit nyní v srpnu, takže životní pouť této architektury by se uzavírala po méně než půl roce. To opravdu moc smyslu nedává, takže jistý odsun Kabylake - pokud se opravdu objeví - dává jedině smysl. Ano, bylo by hezčí vidět červnový termín (období Computexu), ale i konec léta či začátek podzimu je fajn. Nelze čekat nějaké výrazné změny oproti Skylake, takže kdo bude chtít upgradovat, může rovnou letos na podzim, kdo ne, nechť si buď na Kabylake počká, nebo to odloží ještě o chvíli déle, na 10nm Cannonlake.
Poměrně zajímavě přistoupila AMD ke stanovení parametrů mrňavé karty nejnovější generace Radeon Fury. Zatímco obvykle se u nižších modelů použije GPU s deaktivovanými částmi čipu, případně i nižšími takty, Radeon Fury Nano není ve stream procesorech oproti nejvyššímu modelu nijak osekán, nižší spotřeby a tepelného vyzařování se dosáhlo jinými metodami.
Tou první jsou specifické optimalizace, které AMD představila v APU generace Carrizo. To přináší jednu dílčí část úspornosti maličkého modelu Nano. Druhou částí je metoda výběru čipů pro tento model, kdy, podobě jako u lowpower procesorů, jdou do Nano verze čipy s nízkým leakage, které sice běhají dobře hlavně na nižších frekvencích, ale za cenu daleko lepšího poměru vůči spotřebě, zatímco čipy s vysokým leakage, které dobře snášejí velmi vysoké takty, pokud jsou dostatečně chlazeny, míří do nejvýkonnějších karet Radeon Fury X. A vše do třetice doplňuje jinak nastavené řízení spotřeby PowerTune, kdy se Nano model nepouští do tak vysokých frekvencí jako model X.
AMD tím získala možnost uvést na trh model s výkonem nižším, ale takový, který se vejde i do velmi malých PC a nepotřebuje vodní chlazení. Sama tedy jedno takové představila a výkonu má Nano i tak dostatek na současné hry či cokoli jiného. Tento model tak představuje nový přístup k segmentaci trhu grafických karet. Přístup sice zcela logický, ale dosud obvykle neaplikovaný. AMD si jej vyzkoušela ale již dříve, kupříkladu u procesorů řady FX, kdy kromě standardních modelů s TDP 95 či 125 W jsou na trhu i úsporné verze E s TDP 65 W a nízkým leakage, stejně jako „hodně proudově leakující“ modely FX-9xxx s TDP 220 W.
A teď si představte jednoho dne uvedenou variantu Radeonu Fury Nano nikoli s 28nm. nýbrž s 16nm či 14nm FinFET GPU…
Stále stejně kraťoučké PCB, ale úctyhodně dlouhá karta s úctyhodně přesahujícím chlazením. To je Sapphire Radeon Fury, střední model z nabídky nové generace s on-GPU HBM pamětmi. Na rozdíl od Radeonu Fury X či malého Fury Nano na nízkých taktech ale nenese „plnotučné“ GPU s 4096 stream processory, pouze s 3584. Vzhledově opět evokuje některé dřívější karty (namátkou si vybavuji některé modely GeForce GTX 670 či GeForce GTX 750 /Ti) , kde samotné PCB bylo tak kraťounké, že jej o desítky procent prodlužoval blok vzduchového chladiče. V tomto případě je to zhruba 1/2 délky navíc.
Otázkou je, která varianta se do budoucna stane majoritní. Vzduchem chlazené grafiky jsou osvědčená koncepce, na druhou stranu ale je potřeba čas od času pasivní chladič vyčistit. To jistě platí i pro radiátory vodního chlazení, ale vodník umožňuje odvádět teplo dále od karty, resp. od horkého místa, kde se kousek od sebe nachází CPU a GPU, dva „nejnenažranější“ čipy v typickém herním PC.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
vylepšuje zejména práci s velkým množstvím UDP paketů, což je věc klíčová mimo jiné pro online hraní
Máte někdo předstvu, jaký provoz (velikost paketů, počet za sekundu) může taková hra generovat? Měl jsem za to, že dnešní hry jsou navržené tak, aby se daly hrát i přes Internet - a tam má asi málokdo připojení, na které by nestačil i ten nejhloupější gigabitový chipset.
UDP se používá u low latency aplikací a dříve platilo - paket = přerušení CPU
Za prvé: platilo to jen pro příchozí pakety. Za druhé: podpora NAPI v r8169 byla implementována ještě někdy před začátkem gitu (2.6.12, 2005) a od roku 2008 už ani jinak fungovat neumí.
Nejznámější využití je právě u her a hlasu, kde se pohybujete až v řádu stovek za sekundu. viz. typický hlasový provoz je dělený po 20ms + řídící pakety. tj. datově odesílám např. 80kb/s, ale v cca 50-60 paketech/s
To ani zdaleka není něco, s čím by si běžný dnešní hardware (a to ani nemluvím o hardware na hry) hravě neporadil. Uvědomte si, že i při obvyklé MTU 1500 by 100 paketů za sekundu pořád odpovídalo přibližně 150 KB/s. Nebo naopak: spočítám-li si, kolik paketů za sekundu budu potřebovat při MTU 1500 na nasycení 100 Mb/s TCP streamem, dostanu necelých 8000 paketů za sekundu. A to jsem s Realtekem 8139 bez problémů zvládal dávno před NAPI a dávno před TSO/GSO/LRO/GRO.
Takže jestli se bavíme o pouhých stovkách UDP datagramů za sekundu, tak na to žádnou speciální hardwarovou podporu nepotřebujete.
11.7.2015 20:16
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Nejznámější využití je právě u her a hlasu, kde se pohybujete až v řádu stovek za sekundu. viz. typický hlasový provoz je dělený po 20ms + řídící pakety. tj. datově odesílám např. 80kb/s, ale v cca 50-60 paketech/s takže se mi HW specilizovaný na malé UDP pakety vyplatí.50-60 je naprosto ho*no provoz. Navic u audio/video streamu obycejne potrebujete minimalni latence a pri pouziti protokolu na transport layer musite ten interrupt odbavit procesorem jak jen to jde, bez toho ze to hnije nekde v HW packet cache za pouziti interrupt pacing.
Asi jste mne špatně pochopil. Rozhodně jsem nechtěl tvrdit, že 50-60 paketů za sekundu je nějaký problém. Naopak, snažil jsem se připomenout, že ani pro daleko slabší a všemi opovrhovaný 100 Mb/s chipset nebylo před mnoha lety problémem téměř 8000 paketů za sekundu, takže není sebemenší důvod, proč by měl být pro dnešní gigabitové chipsety problém zpracovat stovky nebo dokonce jen desítky paketů za sekundu a proč by na to měl být potřeba nějaký speciální offloading.
Obávám se, že celý tenhle hon za "lepšími" NIC pro online hry bude jen marketingová masáž be reálného základu. Zvlášť když jsem si uvědomil, že o Killer NIC, které mají být považovány za jakousi špičku, jsem vlastně nikdy neslyšel. Tak jsem zkusil Google a vypadla na mne tahle stránka, což je dost nadstandardní kus bullshitu i na poměry marketingových materiálů.
12.7.2015 11:44
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
.
12.7.2015 12:28
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
12.7.2015 21:02
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Spise je to cele skutecne marketingova masaz, jako nazev Dragon a bez snahy urazit mi vase argumentace s 50-60 pakety/s prisla proste usmevnaJá se v tom vůbec nevyznám, ale; Nemůže tam hrát roli to, že samotná hra musí běžet realtime na vysoké frekvenci a do toho ještě handlovat realtime těch 60 packetů? Tedy ta kombinace zátěže od hry?
Hlavní problém je latence a množství malých datagramů
Kolikrát bude ještě potřeba to zopakovat? Stovky datagramů za sekundů nejsou žádné závratné množství paketů; je to desetkrát méně, než v pohodě zvládal i ten nejhloupější 100Mb/s chipset před 15 lety. Latence by být problémem mohly, pokud současně poběží nějaký velký datový tok, ale (1) pro tohle má síťový stack standardní mechanismy a síťovému adaptéru do toho venkoncem nic není a (2) možnosti ovlivnit to ve směru ke mně (kde je to riziko u domácích počítačů větší) jsou hodně omezené a sebelepší NIC na tom nemůže moc změnit.
13.7.2015 14:01
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
Většina multyplayeru stejně běží přes servery někde v internetu tak latence samotného zpracování na straně síťovky bude zanedbatelná vzhledem k samotnému přenosu.Presne tak.
15.7.2015 12:46
little.owl | skóre: 22
| blog: Messy_Nest
| Brighton/Praha
17.7.2015 13:14
BigWrigley | skóre: 33
Mam srovnani. Na DNS balanceru s LVS mam bezne kolem 20.000 UDP paketu/s a to jsou vsechno DNS dotazy, tj. velmi male UDP pakety. Sitovky jsou NC382i (Broadcom BCM5709). CPU je kolem 5% (prakticky vse softirq) a slape to perfektne a pri obcasnem DDOSu to ustoji klidne o rad vice. No a navic, i kdyby se ty nekde nahonilo nejakych +/- 100us, co to bude proti latenci hracovy linky, ze...
17.7.2015 15:26
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Náročné hry nemaje, zkusil jsem ji nasimulovat spuštěním dvou resp. deseti současně běžících instancí "openssl speed rsa2048". Testovaný stroj má dvoujádrový 3GHz Athlon 64 X2, síťový adaptér Marvell 88E8056 integrovaný na základní desce (nějaký starší kousek). Na druhé straně osmijádrový 3.6GHz FX-8150, ovšem v duchu testu s integrovaným Realtek 8168EVL (který používám jen na podobné testy). Spojeno přímo kabelem, abych minimalizoval vnější vlivy.
netperf UDP stream test s 64B datagramy:
netperf UDP_RR request/response test s 64B datagramy:
Není to nějaký důkladný benchmark (koneckonců jsem měl na obou stranách spuštěné běžné desktopové prostředí a na silnějším stroji dva (neaktivní) virtuály), ale jako demonstrace, v jakých řádech se pohybujeme, to snad stačit bude.
Snažně prosím: můžeme konečně akceptovat jako fakt, že stovky krátkých UDP datagramů za sekundu nejsou pro dnešní hardware problémem, a to ani při použití hloupých integrovaných NIC? Pokud někdo chce nadále tvrdit opak, nechť, prosím, své tvrzení podloží aspoň nějakými čísly.
Výsledky UDP_STREAM testu jsou špatně, kvůli chybě ve skriptu jsem bral hodnotu ze špatného řádku (co klient odesílal místo toho, co server opravdu zvládal přijmout a zpracovat). Správné hodnoty jsou
Na závěru to ale pochopitelně nemění vůbec nic.
17.7.2015 21:17
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Snažně prosím: můžeme konečně akceptovat jako fakt, že stovky krátkých UDP datagramů za sekundu nejsou pro dnešní hardware problémem, a to ani při použití hloupých integrovaných NIC? Pokud někdo chce nadále tvrdit opak, nechť, prosím, své tvrzení podloží aspoň nějakými čísly.Já myslím, že se nějak míjíme. Tohle opravdu pro dnešní počítače není problém, co ale (možná) může být problém, je při tom všem zachovat nízké latence nejenom internetu, ale i té hry, renderování, načítání světa, propočtů fyziky a co já vím čeho ještě, což všechno musí běžet realtime, bez lagů a v minimálně 30FPS za vteřinu. Pak bych chápal snahu všechny „vedlejší“ věci co nejvíc outsourcovat do hardware.
Tak ještě jeden zoufalý pokus…
co ale (možná) může být problém, je při tom všem zachovat nízké latence nejenom internetu …
Request/response test je v podstatě "ping-pong", tj. výsledek dává velmi dobrou předstvu o latencích kompletního roundtripu. 5500 paketů za sekundu znamená roundtrip kolem 180 μs - a v tom jsou dvě Tx path, dvě Rx path a ethernet mezi. A co je podstatné, latence se pozorovatelně nezměnila ani když jsem ten stroj, o který by cti dbalý forbesák neopřel koloběžku, přetížil na pětinásobek (deset CPU hogs na dvoujádře).
ale i té hry, renderování, načítání světa, propočtů fyziky a co já vím čeho ještě, což všechno musí běžet realtime, bez lagů a v minimálně 30FPS za vteřinu
Na té "plečce" request/response test, který obnášel 5500 paketů za sekund v každém směru, tj. desetkrát resp. stokrát víc, než o kolika tu byla řeč, spotřeboval 5 procent CPU, na stroji, který (až na grafickou kartu) jakž takž odpovídá tomu, na čem se hry, o nichž je řeč, opravdu hrají, to bylo 1.5 %. A to mám ještě podezření, že netperf ve skutečnosti ukazuje celkovou zátěž procesoru(-ů), ne jen co generuje on sám a síťový stack, protože při testu pod zátěží ukazoval jako "remote" stabilně 100 %. Opravdu vám připadá reálná představa, že by takhle "enormní" zátěž nějak znatelně ovlivnila chování hry?
Prostě se smiřte s tím, že hry jsou extrémně náročné na grafickou kartu, možná i na zvukovou, dost asi zatíží i procesor, ale z hlediska síťové komunikace to nestojí za řeč, každá vytíženější VoIP ústředna se pohybuje řádově výš.
Nemluvě o tom, že na UDP toho stejně k offloadování moc není. Pominu-li generické záležitosti jako VLAN tagging/stripping, které se drtivé většiny týkat nebudou, a checksumming, který ovládá každý aspoň trochu rozumný adaptér, zbývá v podstatě jen UFO, ale pokud je řeč o krátkých paketech s minimální latencí, tak ani to nepřichází v úvahu.
18.7.2015 00:06
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Prostě se smiřte s tím, že hry jsou extrémně náročné na grafickou kartu, možná i na zvukovou, dost asi zatíží i procesor, ale z hlediska síťové komunikace to nestojí za řeč, každá vytíženější VoIP ústředna se pohybuje řádově výš.No, ale to jsem nikdy ani netvrdil. Šlo mi o to, jak to může ovlivňovat latence té hry. Ne sítě, ne kolik to žere výkonu, nebo co já vím čeho. Prostě pokud hra sežere 100% procesoru pro sebe, tak to třeba může vadit. Jenže celá tahle diskuze vypadá, jak kdyby se všichni rozhodli, že se nad tím člověk nesmí ani zamyslet.
Proč já se s tím komentářem vůbec píšu? :-(
Šlo mi o to, jak to může ovlivňovat latence té hry.
Tomu jsem věnoval celý odstavec. Na desetinásobný UDP provoz mi stačí 1.5 % CPU. To si vážně myslíte, že hra na jakémkoli procesoru (které se mezi sebou výkonem liší v desítkách procent) poběží tak na hraně, že jí tohle naprosto rozhodí latence? Jistě, dokázal bych si představit, že by se to tak dalo napsat - jenže pak by jí stejně nepomohla sebelepší síťová karta.
Jenže celá tahle diskuze vypadá, jak kdyby se všichni rozhodli, že se nad tím člověk nesmí ani zamyslet.
Naopak, já bych byl moc rád, kdyby se lidé, kteří tu pořád dokola tvrdí, že stovky krátkých UDP datagramů jsou náročný provoz vyžadující nějakou speciální hardwarovou podporu, nad tím konečně zamysleli - místo toho, aby bez jakéhokoli reálného základu naplňovali význam zkratky FUD (Fear - Uncertainity - Doubt).
18.7.2015 14:33
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Proč já se s tím komentářem vůbec píšu?To nevím. Až to budeš vědět, tak rovnou napiš i proč píšeš, že nevíš proč to píšeš.
Tomu jsem věnoval celý odstavec. Na desetinásobný UDP provoz mi stačí 1.5 % CPU. To si vážně myslíte, že hra na jakémkoli procesoru (které se mezi sebou výkonem liší v desítkách procent) poběží tak na hraně, že jí tohle naprosto rozhodí latence?Dokážu si to představit, ale nemám na to žádný konkrétní názor. Beru to prostě jako hypotézu. Viděl jsem pár talků Carmacka ohledně renderování pro Oculus na 120FPS pro obě oči, počítání fyziky a snímání hlavy na 1000Hz. To mi trochu dalo představu, co všechno se děje na pozadí a jaká magie se tam musí dělat, aby to běželo plynule.
Naopak, já bych byl moc rád, kdyby se lidé, kteří tu pořád dokola tvrdí, že stovky krátkých UDP datagramů jsou náročný provoz vyžadující nějakou speciální hardwarovou podporu, nad tím konečně zamysleli - místo toho, aby bez jakéhokoli reálného základu naplňovali význam zkratky FUD (Fear - Uncertainity - Doubt).Já bych byl zase docela rád, kdyby ses zamyslel nad tím, že to prostě může pomoct, ne že je to 100% nutné. Ty ses prostě nábožensky rozhodl, že je to k ničemu. Udělal jsi jeden test na vlastním hardware, bez toho aniž bys to kdy měl v ruce a vše je ti jasné. Mně ne.
Ne, já jsem se nerozhodl nábožensky. Rozhodl jsem se na základě toho, že vím něco málo o tom, jak síťový stack a síťová komunikace funguje, mám představu, co je schopen zvládat, a že má zkušenosti s jinými aplikacemi náročnými na CPU, které zároveň potřebují komunikovat pö síti při zachování přijatelných latencí. Ale přijde mi hodně ubohé, když člověk, který zatím nepřišel s ničím konkrétním a trousí samé mlhavé náznaky a pochyby, obviní toho, kdo na rozdíl od něho ukázal zcela konkrétní čísla ukazující, že se bavíme o provozu řádově menším, než při jakém by mohly nastat první problémy, že se "nábožensky rozhodl".
Zkuste aspoň konkrétně říct, co byste vlastně do NIC chtěl offloadovat, aby to pro provoz, o kterém se tu bavíme, tj. stovky krátkých UDP datagramů za sekundu, mělo šanci vůbec něco přinést.
Šlo mi o to, jak to může ovlivňovat latence té hry.Kristova noho!!!
18.7.2015 14:36
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz