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.
Tak jsem opět tu s dalším dotazem,
V rámci uvažovaného přechodu na btrfs bych se rád zeptal na zkušenosti/současnou situaci v provozování virt.serverů a databází na btrfs.
Z různých článků a diskusí, ostatně i z oficiálních stránek btrfs se pro tyto účely nedoporučuje využívat COW a tuto nad těmito věcmi vypnout - at už volbou při montování či přidání attributu na soubor/adresář. Tím samozřejmě ale přicházím i o některé výhody btrfs.
Na systému by běžely virutály - qemu-kvm (libvirt ...) a databáze MySQL a Pervasive PSQL. Prozatím sem vidě porovnání btrfs a Postgresql , které vyznělo příznivě.
Jaká je tedy současná situace? Je nějaká změna a hodí se tedy btrfs na server, kde většinou poběží virtuály?
Díky za postřehy a zkušenosti
a přihodil bych další dotaz, který určitě vyvolá vášnivé diskuse
- vyplatí se přechod na btrfs z ext4? co mi to přinese (pominu-li snapshoty)
To, že práce s btrfs je trochu odlišná od dosavadního ext4 je jasné (už jen zjištění volného místa...)
takž krom snapshotu, RAID pole co více mi to přinese? (čistě mechanické HDD, žádné SSD - raději předem doplním). (pocítím rychlost zpracovávaných operací? lepší režii? menší vytížení CPU oproti stejné práci nad ext4....)
Asi hříšný dotaz, ale risknu to.
4.1.2015 13:00
Max | skóre: 72
| blog: Max_Devaine
4.1.2015 13:08
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
To porovnání výkonu postgresu na btrfs a ext4 se mi zdá příliš optimistické. Co jsem testoval (pravda, je tomu už déle než rok), tak tps bylo na btrfs poloviční (což celkem odpovídá tomu, co ten fs musí dělat navíc). A také to celkem odpovídá pomalosti btrfs při fsync (což db dělá na konci každé transakce). V každém případě je asi čas na nový test na aktuálním jádru a na pg 9.4. .
jak jsem psal, nemám s tímto zkušenosti a jen čerpám znalosti - a porovnání z roku 2014, jak je v článku, mi přijde celkem aktuální, ani bych ho jinak neuváděl :)
jinak jak jsem psal už jinde - reakce - taktéž považuji za nerozumné dělat btrfs snapshot virtuálu, když si to můžu udělat ve virtuálu :D, žádný přínos v tom nevidím.
Jak jsem psal, jde mi spíš o to, jestli při přechodu na btrfs nedojde ke zhoršení práce ve virtuálu at už z jakýchkoliv důvodů - jsou uvedeny v odkazu na mou reakci výše (viz odkaz)
6.1.2015 09:40
Heron | skóre: 53
| blog: root_at_heron
| Olomouc
Databáze COW nepotřebují, protože se umí obnovit samy (mají vlastní žurnál).
Tak on COW není jen pro obnovení po pádu. Já mám v todo listu (viz tento článek) vyzkoušet běh PG na BTRFS a jednak otestovat rychlost (po letech), ale hlavně otestovat snapshoty subvolume s DB s tím, že by se potom ta db spustila nad daným snapshotem. Pro velmi rychlé obnovení po nějaké hodně škaredé operaci (někdo omylem udělá DROP DATABASE nad nějakou 500GB databází, která by se obnovovala půl dne). Pokud by to šlo bez poškození dat (což by bez problémů jít mělo) spustit nad snapshotem, tak by to bylo v rámci sekund (v podstatě by stačilo spustit jen pg_ctl -D snapXY).
Na jednom disku zapisuje Btrfs v implicitní konfiguraci dvě repliky všech metadat (RAID režim zvaný DUP) a navíc dělá checksumy dat i metadat. (Na diskových polích RAID 0 a 1 zapisuje vždy jednu repliku metadat na každý disk, tj. metadata jsou implicitně v režimu RAID 1, i když jsou data v režimu RAID 0, dokud to uživatel nenastaví jinak. Checksumy se samozřejmě počítají rovněžtak.) Na tohle všechno je třeba pamatovat jak při porovnávání výkonnosti vzhledem k filesystémům bez redundance a bez checksumů (Ext4), tak i při konfiguraci Btrfs. (Například na některých logovacích filesystémech jsem měl nejen data, ale i metadata v režimu RAID 0, protože z jejich případné ztráty bych se příliš neposral.)
Pokud jde o virtualizaci, zásadní výhodou je klonování disků virtuálních strojů v téměř konstantním čase. Pokud ovšem není třeba klonovat disky nebo jinak využívat CoW, výhody Btrfs na serveru se úplně vytrácejí. Například pokud uvnitř VM běží taktéž Btrfs, je možná škoda dělat checksumy na dvou úrovních zároveň a mohlo by být lepší mít na serveru prostě LVM oddíl a vše ostatní už nechat na virtuálním stroji a na jeho interním Btrfs/ZFS/něčem podobném.
Pokud jde o klasické úvahy o virtuálních discích v souborech na Btrfs a případné fragmentaci způsobené CoW, na SSD takový problém v podstatě neexistuje a na klasických discích mám tu zkušenost, že buď autodefrag zvládl svou práci dobře, nebo se díky zápisům dlouhých a nepřerušených sekvencí bloků ze strany virtuálního stroje celková fragmentace souboru s virtuálním diskem udržela v nějakých rozumných mezích. Zkrátka a dobře, navenek se to projevovalo tak, že virtuální stroj prostě rozumně fungoval i po mnoha aktualizacích systému a databázových experimentech všeho druhu a že se nedostavil žádný patologický stav, při kterém by ten klient bootoval déle než deset sekund nebo něco takového. To ale neznamená, že se to na jiné konfiguraci s jinými workloady nemůže úplně rozsypat. 
Třeba může, co já vím.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
4.1.2015 11:41