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í.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
$ uname -r 2.6.35-32-generic $ ./grep --version ./grep (GNU grep) 2.16 # chybí PATTERN - příkaz nefunguje $ ./grep < /dev/zero Usage: ./grep [OPTION]... PATTERN [FILE]... Try './grep --help' for more information. $ ./grep a < /dev/zero ./grep: memory exhausted
Jen teda system behem toho kdy se o prikaz pokousel moc pouzitelny nebyl, ale to je asi tim ze je bezi na stare T43Ne, já mám lepší stroj (Core i3 Sandy Bridge, 8 GB RAM) a vyčerpání paměti znamená 20minutový zátuh. Reportoval jsem to a dozvěděl jsem se, že mám používat menší swap - mám 8 GB RAM a 1,3 GB swapu. Od té doby jsem názoru že Linux prostě neumí spravovat operační paměť. V LKLM hnije patch, ale nevypadá to, že by to někdo řešil.
$ yes "nejoblibenejsi nekonecne dlouhy prikaz"| head -c 100000000 > test.txt $ grep >/dev/null nej ./test.txtPropustnost:
LANG=cs_CZ.utf8 grep 142.3 MB/s LANG=C grep 320.5 MB/sSamozřejmě mezi jednotlivými měreními je nutné vyprázdnit IO cache, např:
# echo 3 > /proc/sys/vm/drop_caches; sync
Záleží co chceme benchmarkovat. Já to pochopil, že propustnost při praktickém používání grep a tam záleží i jak to čte z disku.
Pokud mne zajímá propustnost grepu, je potřeba, abych opravdu měřil propustnost grepu. Pokud budu číst ze vstupu, který nebude schopen poskytovat data tak rychle, aby byl úzkým hrdlem grep, pak neměřím propustnost grepu, ale něco úplně jiného.
Navíc podle těch čísel, která ukazujete, ve skutečnosti ani vy z disku nejspíš nečtete; tipoval bych, že proto, že ten flush děláte před testem a ne mezi vytvořením souboru a spuštěním grepu.
Nejsem si jistý jak je to s VM cache u TMPFS, ale tipnul bych si, že se asi taky použije.
Použije - ale jinak, než si myslíte: tmpfs je vlastně page cache, která pod sebou nemá žádné zařízení. Takže flushnout nejde, protože kdyby se vám to nějakým způsobem podařilo, o data přijdete.
Tudíž doporučuji i tam flushovat, aby měření nebylo ničím ovlivněno, nic se s tím nezkazí.
Nezkazí - ale také to nemá žádný efekt.
Co se týká DOSu při HTTP upload, každý rozumný člověk tam má nějaký limit.Nevím jestli jde nastavit limit pro všechny klienty dohromady. Umím to jenom per-request. Ale nezkoumal jsem to podrobně. (a nejlepší řešení by bylo neukládat proboha celý POST do paměti) A nevím, jak jsi přišel zrovna na tento případ, já si zatím složil počítač 1) vlastním programem s bugem který prostě naalokoval a použil strašně moc paměti, 2) pokusem o napsání make -j 4 s vypnutým numlockem, takže to spustilo 200 instancí g++, 3) otevřením několika 100MPx obrázků ve Firefoxu.
20 minutové zátuhy lze umravnit vypnutím swapTo má negativní dopad na výkon.
nebo alespoň vypnutím overcommit při alokaci pamětiS tím mi nefungovalo Wine a možná nebude fungovat i něco dalšího.
Nevravim, ze nemas pravdu, len napisem svoje skusenosti: Na desktope mi zvycajne prislo lepsie, ked aplikacia hned spadla pri nedostatku pamati, nez ked predtym 10 minut nechala pocitac nezmyselne swapovat. Podla mna ma v tomto pripade swap zmysel jedine v pripade, ze pouzivas aplikaciu ktora proste potrebuje vela virtualnej pamati a pridanie RAM nie je moznost. (ci uz financne, alebo technicky, ale to potom pouzivas bud nepsravny SW alebo HW..) Jediny realny zmysel swapu vidim v suspend to disk ale este som nemal to stastie ze by to niekde fungovalo 100% vzdy, takze to beztak nepouzivam. Na server podla mna vo vacsine pripadov swap nepatri vobec, lebo ak sa co i len blizi vyuzitie pamati 100% tak je cas na optimalizaciu SW aby bol pamatovo efektivnejsi, alebo na viac HW. Zvlast v dobe EC2 a pod. je IMHO lepsie nechat server/service spadnut a nechat loadbalancer nastartovat sluzbu na inom stroji, nez mat 10 minut latenciu taku, ze je server prakticky nepouzitelny. (a uzivatel trpi) Pravda, ak na HW nie su peniaze, tak si asi clovek nepomoze, ale to je skor financny problem, nez technicky.20 minutové zátuhy lze umravnit vypnutím swapTo má negativní dopad na výkon.
Man grep:
fgrep is the same as grep -F
-F, --fixed-strings
Po prvním dílu jsem doufal, že to byl jen takový pomalý a trochu zmatený rozjezd a že zbytek už bude lepší. Teď už se jen děsím, co bude příště.
Já to sem radši psát nebudu, protože vím, v kterém článek píšu, je defektní a když je v textu khmerština, při editaci maže jiné části textu než co ukazuje že maže, což vede k závažnému poškození dat.
tady se mi, již dost krabatá, šedá kůra ještě více zkrabatila. nejdřiv jsem si položil otázku, co autor ví. první, co mne napadlo, že autorovi vypadl defektní jazyk:
Já to sem radši psát nebudu, protože vím, že jazyk v kterém článek píšu, je defektní a když je v textu khmerština, při editaci maže jiné části textu než co ukazuje že maže, což vede k závažnému poškození dat.
ale to mi nedával smysl zbytek souvětí, nehledě na fakt, že z toho vyplývající autorovo přesvědčení o defektní češtině mi zvedal krevní tlak. Uklidniv jej odkázáním do patříčných mezí jeho, jal jsem se prošetřovati další hypotézu a to obrácenou, že tam je něco navíc. Tato hypotéza se ukazuje býti nejpravděpodobnějsí. Doufám, že autor už též objevil, kde mu co přebývá.
vím → vim :-)
Ale taky mi chvíli trvalo, než mi to došlo.
Myslím, že tam mělo být "že redakční systém".
Taky mě první napadl jazyk, pak cosi o defektním autorovi, a nakonec jsem se snažil vymyslet, proč a hlavně co za speciální znak použil z khmerštiny, že se to umazalo.
Redakční systém je pravděpodobnější než vim vzhledem k autorově stylu psaní. A i vzhledem k tomu, jestli vim neumí khmerštinu.
jenda hard rss 6000000
(na stroji s 8 GB RAM) a stejně ho dokážu položit (viz bugreport výše).
Tiskni Sdílej: