Promethee je projekt, který implementuje UEFI (Unified Extensible Firmware Interface) bindingy pro JavaScript. Z bootovacího média načítá a spouští soubor 'script.js', který může používat UEFI služby. Cílem je vytvořit zavaděč, který lze přizpůsobit pomocí HTML/CSS/JS. Repozitář se zdrojovými kódy je na Codebergu.
Zpráva Justičního výboru Sněmovny reprezentantů upozorňuje na cenzurní kampaň Evropské komise, mířenou proti svobodě projevu na sociálních sítích. V dokumentu se uvádí, že se Evropská komise během posledních šesti let účastnila více než 100 uzavřených jednání, během nichž po platformách požadovala úpravy pravidel moderování obsahu, přičemž toto úsilí Komise zahrnovalo i cenzuru politických názorů a pravdivých informací. Výbor zdůrazňuje, že tento přístup Bruselu ohrožuje ústavou zaručená práva Američanů na svobodu projevu.
Linus Torvalds vydal jádro Linux 6.19. Podrobný výčet změn je ke zhlédnutí na stránce Kernel Newbies, stručné výběry v LWN (část první, druhá).
Do prodeje jde tichá bezdrátová herní myš Logitech PRO X2 SUPERSTRIKE s analogovými spínači s haptickou odezvou (HITS, Haptic Inductive Trigger System). Cena je 4 459 Kč.
Microsoft na GitHubu zveřejnil zdrojový kód projektu LiteBox, jedná se o 'knihovní operační systém' (library OS) zaměřený na bezpečnost, využívající systémovou architekturu LVBS k ochraně jádra před útoky z uživatelského prostoru. LiteBox je napsán v Rustu a uvolněný pod licencí MIT. Projekt je teprve v rané fázi vývoje.
BreezyBox je open-source shell a virtuální terminál pro populární jednočip ESP32. Nabízí základní unixové příkazy, sledování aktuálního pracovního adresáře (CWD), jednoduchý instalátor a spouštěč aplikací v podobě ELF binárních souborů, zabudovaný HTTP server nebo třeba ovládání WiFi - ukázka použití coby 'malého osobního počítače'. Ačkoliv je BreezyBox inspirovaný BusyBoxem, oproti němu má tento projekt několik externích závislostí, zejména na ESP-IDF SDK. BreezyBox je dostupný pod licencí MIT.
Byl představen cross-assembler xa.sh, napsaný čistě v Bourne shell skriptu. Tento nástroj umožňuje zpracovávat assemblerový kód pro Intel 8080, přičemž je možné snadno přidat podporu i pro další architektury, například 6502 a 6809. Skript využívá pouze různé běžné unixové příkazy jako jsou awk, sed nebo printf. Skript si lze stáhnout z GitHubového repozitáře projektu.
Byla představena nová verze modelu Claude Opus 4.6 od společnosti Anthropic. Jako demonstraci možností Anthropic využil 16 agentů Claude Opus 4.6 k vytvoření kompilátoru jazyka C, napsaného v programovacím jazyce Rust. Claude pracoval téměř autonomně, projekt trval zhruba dva týdny a náklady činily přibližně 20 000 dolarů. Výsledkem je fungující kompilátor o 100 000 řádcích kódu, jehož zdrojový kód je volně dostupný na GitHubu pod licencí Creative Commons.
Kultovní britský seriál The IT Crowd (Ajťáci) oslavil dvacáté výročí svého prvního vysílání. Sitcom o dvou sociálně nemotorných pracovnících a jejich nadřízené zaujal diváky svým humorem a ikonickými hláškami. Seriál, který debutoval v roce 2006, si i po dvou dekádách udržuje silnou fanouškovskou základnu a pravidelně se objevuje v seznamech nejlepších komedií své doby. Nedávné zatčení autora seriálu Grahama Linehana za hatecrime však vyvolává otázku, jestli by tento sitcom v současné Velké Británii vůbec vznikl.
Společnost JetBrains oznámila, že počínaje verzí 2026.1 budou IDE založená na IntelliJ ve výchozím nastavení používat Wayland.
Používám linuxový SW raid (verze 1.2). Jenže ten je až pod LVM, takže s ním DRBD vůbec nepracuje.Šlo o to, že DRBD potřebuje mít jistotu, že je na disku fyzicky aktualizována bitmapa bloků v metadatech, než se začnou zapisovat další data. Jinak by při nekorektním ukončení systému (výpadek napájení) mohla být DRBD metadata nekonzistentní se skutečným stavem. Když máte HW RAID z baterii, tak je za "fyzickou aktualizaci" uvažován už zápis do writeback cache na RAIDu, a disk kvůli tomu nemusí dělat hned seek. I proto se Linbit vyjadřuje ve smyslu "DRBD jedině s HW RAIDem a BBWC, jinak se ničemu nedivte". Takže u SW raidu buď může dojít k nekonzistenci, nebo je tam degradace výkonu při určitém typu žátěže. Nevýhody HW RAIDu jsou jasné, ale pokud se u toho clusteru použije u každého uzlu karta jiného výrobce, tak se ta rizika podle mě omezí.
Mimochodem, není bez zajímavosti, že velmi podobně navrhnul své centrální úložiště i Zdeněk Burda, na jehož blogpost mě upozornil kolega v době kdy už jsem si sepisoval poznámky ke kapitolce o DRBD.Ono to na linuxu moc jinak udělat nejde, natož pak lépe. Ano, ten blogspot je dobrý.
Tady už bruslím na tenkém ledě, ale myslím, že právě proto se nad drbd v režimu Master/Master používá OCFS2, které data replikuje na úrovni souborového systému.No to nevím. Podle mě OCFS2 o nějakém DRBD vůbec nic neví. OCFS2 prostě předpokládá, že máte na všech strojích sdílené blokové zařízení. Typicky exportované z nějakého externího pole/SAN přes iSCSI nebo Fibre Channel. V prostředí, pro které je OCFS2 primárně určen, je DRBD taková nouzovka, pokud nemáte dost peněz na SAN. OCFS2 jako nakonec asi každý clusterový filesystem (třeba GFS) má vlastní lock manager, který mezi uzly komunikuje přes síť a řeší synchronizaci přístupu / zámky.
Když chcípne jeden stroj, tak se při nahazování data nejprve synchronizují z disku který zůstal běžet tak aby se nenabourala jiná data,Tohle dělá DRBD. S tím OCFS2 téměř jistě nemá nic společného, protože o DRBD nic neví.
s tím že případné zbylé nekonzistence se pak již řeší na úrovni souborového systému.To je něco jiného. DRBD metadata slouží hlavně k tomu, aby se po výpadku poznalo, které bloky na "neaktuálním" disku byly v době výpadku změněny, aniž by se musely projíždět oba celé disky. Kvůli tomu je velmi důležité držet konzistenci těch metadat a pořadí zápisů. Jinak může dojít k tomu, že DRBD resource bude ve stavu Consistent, ale data na obou stranách se budou lišit. I proto je možné a asi i dobré občas spustit kompletní kontrolu konzistence dat na obou stranách. Vše je popsáno na webu Linbitu. Ale pokud to vše funguje dobře, není to zásadně podstatné. Nejhorší situace, kdy se toto může projevit, je výpadek napájení obou strojů pod I/O zátěží.
Ostatně pro cluster s větším počtem nodů bych zvolil spíše CEPH, nebo GlusterFS, které pracují s rozprostřenými daty.Záleží na typu zátěže a požadovaném výkonu. Je pravda, že tahle SW řešení typu GlusterFS se stávají stabilními až v poslední době. Ale ty firmy, co si kupují drahé SAN systémy, nejsou úplně mimo. Jako hodně zajímavé z této oblasti mi přijde tohle: http://sourceforge.net/apps/mediawiki/vastsky/index.php?title=Main_Page, plánuje se integrace do Xenu.
No to nevím. Podle mě OCFS2 o nějakém DRBD vůbec nic neví. OCFS2 prostě předpokládá, že máte na všech strojích sdílené blokové zařízení. Typicky exportované z nějakého externího pole/SAN přes iSCSI nebo Fibre Channel. V prostředí, pro které je OCFS2 primárně určen, je DRBD taková nouzovka, pokud nemáte dost peněz na SAN.No to se mi moc nezdá. Nemám pocit že by OCFS2 nutně vyžadovalo sdílené blokové zařízení.
Nějak se míjíme v chápání psané věty, protože to co jsem napsal jinými slovy říká totéž.Když chcípne jeden stroj, tak se při nahazování data nejprve synchronizují z disku který zůstal běžet tak aby se nenabourala jiná data,Tohle dělá DRBD. S tím OCFS2 téměř jistě nemá nic společného, protože o DRBD nic neví.
Ne tak docela. Tím nemám ne mysli stabilitu těchto souborových systémů, jako spíš způsob jejich nasazení. Jejich nasazení má totiž smysl až u většího počtu strojů, což je úúplně jiná situace, než v jaké se nasazuje SAN. Krom toho XEN je z hlediska linuxu podle mě mrkev. Dovolím si krapet zavěštit. Na počátku stojí klasická otázka: "Kdo za tím stojí a komu to slouží?". Zajímavá je rivalita v oblasti lokálních souborových systémů ( Ext4 versus Btrfs ), souborových systémů pro menší clustery ( GFS2 versus OCFS2 ) či souborových systémů pro velké clustery ( GlusterFS versus Lustre ). Na jedné straně barikády stojí Red Hat a na té druhé ORACLE. Zajímavé jsou určité invektivy či skoro až pomluvy, které se vůči ORACLE čas od času vynoří. Je to logické, neboť Red Hat se cítí z této strany ohrožen. ORACLE už získal SUN. Firmu která byla v oblasti unixových serverů konkurencí pro Red Hat a vyvíjela kancelářský balík. S ní i řešení pro lokální virtualizaci. Kdyby ORACLE spolknul Red Hat, tak by se defakto dostal do přímé protiváhy Microsoftu, neboť by byl schopen nabídnout naprosto stejné alternativní spektrum služeb. Od desktopu po virtualizační platformu. Ovšem na rozdíl od Microsoftu staví ORACLE přes veškeré poplašné zprávy jak se zdá svou budoucnost na open source platformě, neboť si je dobře vědom že takto má k dispozici tisíce vývojářů a miliony testerů, které by nikdy nebyl schopen zaplatit.Ostatně pro cluster s větším počtem nodů bych zvolil spíše CEPH, nebo GlusterFS, které pracují s rozprostřenými daty.Záleží na typu zátěže a požadovaném výkonu. Je pravda, že tahle SW řešení typu GlusterFS se stávají stabilními až v poslední době. Ale ty firmy, co si kupují drahé SAN systémy, nejsou úplně mimo.
No to se mi moc nezdá. Nemám pocit že by OCFS2 nutně vyžadovalo sdílené blokové zařízení.Tak na co tam pak řešíte DRBD? DRBD dělá replikaci a nad tím OCFS dělá replikaci ještě jednou? DRBD není nic jiného, než "virtuálně" sdílené blokové zařízení. V Active/Active se to na obou strojích tváří jako by to bylo nějaké sdílené diskové pole.
Nějak se míjíme v chápání psané věty, protože to co jsem napsal jinými slovy říká totéž.Ano, špatně jsem to pochopil.
Ne tak docela. Tím nemám ne mysli stabilitu těchto souborových systémů, jako spíš způsob jejich nasazení. Jejich nasazení má totiž smysl až u většího počtu strojů, což je úúplně jiná situace, než v jaké se nasazuje SAN.To asi ano, oblast je jiná. Přesto pro účely provozního uložení obrazů disků virtuálních strojů považuji SAN za nejlepší řešení. Pokud potřebujeme storage pro soubory, pak se mi třeba GlusterFS líbí víc. Jistě záleží na typu žátěže pro ty virtuální stroje, pokud půjde o I/O výkon a latence, tak SAN řešení musí vyhrát už z principu složitosti a počtu vrstev. Další otázkou je spolehlivost, kde ale teorie dosti selhává - každopádně u distribuovaného FS data prochází daleko větší logikou a větším množstvím kódu než v případě [ diskové pole - FC síť - FC HBA ]. V oblasti enterprise virtualizace ani nikdo jinou cestou než SAN storage nejde ... ale i tam to možná přijde.
Krom toho XEN je z hlediska linuxu podle mě mrkev. Dovolím si krapet zavěštit.Z hlediska linuxu možná. XEN rozhodně jen tak neumře, Citrix na něm má postaveno dost zajímavých produktů. A vývoj je OSS. Ale je to koncipováno spíš jako "blackbox" typu VMWare ESX.
"It is also a shared disk cluster file system, one that allows multiple nodes to access the same disk at the same time"O replikaci tam nic nevidím, i když by mě to potěšilo. Ale oni by se o tom jistě zmínili. Všechny návody, co jsem viděl, používaly OCFS nad DRBD nebo se počítalo třeba s nějakým sdíleným iSCSI polem. Je to stejný typ filesystemu jako RedHat GFS.
Věc se má tak, že nejdřív tam bylo DRBD a teprve následně jsem hledal vhodný FS. Faktem je, že v kombinaci s OCFS se mi prakticky nestalo, že by mi vznikla nekonzistence, kvůli níž by bylo nutné provést synchronizaci.S OCFS je výhoda, že máte jen jeden DRBD resource, trvale ve stavu Active/Active. Třeba XenServer tohle řeší tak, že nad sdíleným diskem má jen LVM se kterým ale dělá různá kouzla kvůli snapshotům. Mají to nějak vyřešené, že není potřeba ani cLVM. Nebo nechávají správu oddílů pro VM přímo na SAN vrstvě (StorageLink).
Lokální SW RAID vytvořený z nbd zařízení. Každý nod má vyexportováno jedno blokové zařízení. Takže /dev/nbd0 je připojený přes 127.0.0.1 a zbytek( /dev/nbd1, ...) po síti.Jasně, tohle je taky možnost. Ale DRBD lépe řeší ty potenciálně nekonzistentní situace. A počítá s tím, že "každou chvíli není dotupný některý z disků", na což mdraid není úplně stavěný.
U kombinace DRBD + OCFS2 byla rychlost kopírování kolem 56M/sKopírování z jednoho disku na ten samý, nebo např. z
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz/dev/zero na disk? Protože tam, kde mám DRBD nad HW RAIDem s BBWC je při zápisu evidentně limitem replikační Gb Ethernet. Byl bych rád, pokud byste napsal, na jakou rychlost sekvenčního zápisu se dostane KVM virtual machine nad OCFS2+DRBD+mdraid. A ideálně i jak rychlý je stejný zápis přímo na lokální mdraid bez DRBD. V mém případě Xen VM zapisuje z /dev/zero na DRBD replikovaný disk rychlostí 120 MB/s (VM filesystem ext3, 15 GB soubor, čas dd+sync, replikační Eth celou dobu na 997000 kbit/s). Pod DRBD tady na testování mám na obou stranách kartu HP SmartArray 212, RAID10, 4 obyčejné SATA disky. Sekvenční čtení souboru uvnitř VM je cca 200 MB/s.
syncer {
# it's recommended to use 30 % of GbE
rate 33M;
verify-alg sha1;
}
syncer rate se uplatňuje v okamžiku resychronizace, např. pokud jeden z uzlů nějakou dobu neběžel. Nastavení se doporučuje udělat tak, aby resychnronizace využila třetinu linky, a zbytek byl volný pro provozní zápisy.
Byl bych rád, pokud byste napsal, na jakou rychlost sekvenčního zápisu se dostane KVM virtual machine nad OCFS2+DRBD+mdraid. A ideálně i jak rychlý je stejný zápis přímo na lokální mdraid bez DRBD.Zkusím na to pamatovat. Až to otestuji, tak bych to upíchnul nejspíš opět do blogu, jako samostatný blogpost. Tady by to zapadlo. Každopádně díky za konkrétní čísla.
To je sice pravda, nicmene je treba vzit do uvahy ze:
Navic (aspon pokud jsem to spravne pochopil) Linbit HeartBeat spis udrzuje nez vyviji dal, coz nemusi byt v kratkodobem horizontu problem, ale v dlouhodobem byt muze.
.., i když doba výpadku je větší (nestačí třeba přehodit IP adresy, ale musí se nabootovat celý VM) a nedá se tím řešit výkon jedné aplikace.To není až tak docela pravda. U KVM lze přemigrovat stroj zaživa bez výpadku - prakticky odzkoušeno. Mimochodem, to je taky důvod proč jsem se v tom Pacemakeru začal hrabat až tak do hloubky - abych si udělal agenta pro KVM na míru, bez nutnosti používat libvirt, který má ony požadované funkcionality prozatím toliko v TODO. Bohužel "céčko" až tak dalece neovládám. Zpracovávat XML shellovým skriptem mi přijde jednodušší. Jinak bych to byl do toho libvirtu dodělal.
To není až tak docela pravda. U KVM lze přemigrovat stroj zaživa bez výpadku - prakticky odzkoušeno.Jasně, ale to beru spíš jako takovou věc navíc. Pokud mluvíme a vysoké dostupnosti, tak beru jako zásadní mít co nejkratší neplánované výpadky. Tj. jak dlouho to nepůjde, když aktivní uzel nečekaně zkolabuje (výpadek napájení ze všech zdrojů, vyhořelý HW apod.). A v tomto případě stroj musí nabootovat znovu. I když Xen má funkční (experimentální) implementaci realtime replikace obsahu RAM na druhý uzel, takže pak k pádu OS nedojde. Jsou s tím samozřejmě principielní problém, hlavně co se týče výkonu.
abych si udělal agenta pro KVM na míru, bez nutnosti používat libvirt, který má ony požadované funkcionality prozatím toliko v TODOKvůli nutnosti použít libvirt, který se mi zdál příliš komplikovaný, jsem dříve raději použil Xen. Protože pro něj je Heartbeat/Pacemaker agent skutečně triviální a hotový. Pro KVM jsem tehdy našel jen řešení přes libvirt, a to mi přišlo jako zbytečná potenciálně chybová vrstva. A jak píšete, možná požadované funkce ani neumí.
Tiskni
Sdílej:
