Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
Zdravim vsechny,
mam na stole navrh serveru, ktery by mel byt vyuzit pro virtualizaci (KVM), servery by se meli koupit dva ve stejne konfiguraci.
Jaky je vas nazor na tuto sestavu? Zajima me hlavne RAID radic, ktery by mel vytvorit dve pole
1x RAID1 mirror pro system (zde nejspise navrhnu mensi disky jelikoz na nich bude malo dat)
1x RAID6 nad zbyvajicim 4x 1TB disky pro DATA (kapacitne to vychazi na 2TB, tolerance pro vypadek 2 disku)
(klidne navrhnete jine rozdeleni, mozna bude lepsi lepsi pouzit cele pole pro system i data)
---
INTEL RAID Controler (Big Laurel 4) PCIe x8, RAID 4x SAS 6Gb
INTEL RAID Smart Battery - battery back up for use with Intel
2x INTEL Quad-Core Xeon E5620 2.40GHZ/12MB/ LGA1366
INTEL Server platforma (Urbanna) 2U, 2x LGA1366, 6x 3,5"
INTEL Backplane 6th SAS/SATA drive kit 3,5"
KINGSTON 24GB 1333MHz DDR3L ECC Reg CL9 DIMM
6x Seagate Constellation ES - 1TB/7200rpm/SATA-6G/64MB
---
Moje predstava je nad diskovym polem pro data vytvorit konfiguraci DRBD a replikovat data na druhy uzel a pokud to bude mozne tak toto provadet v obou smerech (myslim, ze to DRBD umoznuje), chci pro virtualizaci pouzit oba stroje a ne mit jeden pouze jako online zalohu.
Co je rozumejsi?
1) replikovat cely raid6 pres drbd, nad timto postavit LVM a to nasledne rozkrajet do virtualinich stroju?
2) nebo na raid6 udelat lvm, nad lvm nasledne drbd a replikovat
Virtualizace HDD (blockove zarizeni nebo soubor qcow2?)
- jde mi o vykonove propady jednotlivych moznosti, zalohovani (lvm snapshot chapu, lze zalohovat i bezizi stroj s qcow2?), online migrace ma nejaky dopad pouziti blokoveho zarizeni/qcow?
Jak zajistujete dnes problem s vypadkem jednoho uzlu + nastartovani sluzeb/stroju na druhem? Hearbeat mi prijde dnes jiz celkem zastaraly koukal jsem na corosync a peacemaker, ale nedokazu si z toho vybrat, ale je mi vcelku jasne, ze rozpad takoveho dvou uzloveho reseni se musi nejak resit, nejspise sluzby nastartuji na jednom uzlu a nasledne po synchronizaci se migruji na druhy.
Celkem se mi libi projekt proxmox, ale radeji bych obdobne reseni s KVM na CentOS6, existuje neco takoveho nebo je treba rucne poresi konfiguraci vseho?
Diky za info snad jsem to prilis nesaturoval. FAHA
Diky,
RAID10 me uplne vypadnul z hlavy, cteni bude rychle a jeste se zbavim parity pri zapisu.
---
DRBD v režimu master-master možná je, ale složitější je to pak s filesystémem na ni, pokud chcete mít připojené na obou strojích stejné oblasti, tak tam musíte mít clusterový filesystém (GFS2, ocfs). Pokud budete mít v jednu chvíli připojenou oblast jen na jednom serveru, tak je to ok.
---
Za predpoklady, ze budu pouzivat pouze lvm oddili nad DRBD pro beh virtualnich stroju (tedy zadny oddil s fs, ktery bude pripojeny primo ve fyzickem stroji) tak GFS2 nepotrebuji, uprimne bych se tomuto chtel uplne vyhnout protoze je to trochu divocina.
Diky.
RAID10 bude, 15k disky by byly fajn, ale neverim ze to protlacim cenove, uz ted je to dost napnute, navic bohuzel by se mi asi tezko vysvetlovalo proc v tech virtualech jsou dva disky lidem, kteri jsou zvykli vsechno davat na 1disk, ale popremyslim o tom.
24GB pameti jsem prosadil na zacatku, pokud bude potreba dokoupi se, RAM je aktualne levna, Kernel Same Page (KSM) planuji nasadit, pokud na tom pobezi CentOS6 tak to nebude problem je jiz soucasti, deduplikaci bych zabranil velmi rad.
grep KSM /boot/config-2.6.32-71.29.1.el6.x86_64
CONFIG_KSM=y
Zalohovani budu muset resit a prave LVM snapshot mi prisel jako nejsnadnejsi cesta, chapu co jste mi chtel rict, budu o tom premyslet.
Migrace s KVM urcite jde, videl jsem ji na vlastni oci, bohuzel se se storage na fibre channelu coz je jina liga. Moje predstava je, ze by to melo probihat v mem scenari takto, data jsou online replikovana na druhy uzel a tudiz by na druhem stroji mela byt v tu chvili konzistenni, pri migraci se aktivni uzel pokusi prenest cast pameti VM, nasledne zastavi stroj a prekopiruje zbytek pameri, ktera se mu menila "pod rukama", poto spusti stroj na druhem uzlu, vzhledem k tomu,ze usporadani dat/oddilu je identicke tak by to snad melo jit.
proc v tech virtualech jsou dva disky lidem, kteri jsou zvykli vsechno davat na 1diskJe to běžná praxe...
grep KSM /boot/config-2.6.32-71.29.1.el6.x86_64 CONFIG_KSM=yJen pro úplnost - to nestačí, je to ještě potřeba zapnout po startu stroje.
Moje predstava je, ze by to melo probihat v mem scenari takto, data jsou online replikovana na druhy uzel aByl bych opatrný v jakém stavu je stav replikovaného disku ve chvíli kdy se migruje virtuálka. Může být že replikace disku ještě nedoputovala na druhý stroj... ale asi to už někdo nějak řešil? Jinak ten fibre channel je samozřejmě nejlepší řešení. Nebo se prostě na živou migraci vykašlat a akceptovat nějaký downtime.
Tiskni
Sdílej: