Byla vydána verze 1.96.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Společnosti IBM a Red Hat představily Project Lightwell s investicí 5 miliard dolarů. Jedná se o důvěryhodné clearingové centrum pro bezpečnost open source softwaru a zabezpečení dodavatelských řetězců s novým AI modelem a globální skupinou více než 20 000 softwarových inženýrů. Služby centra budou dostupné prostřednictvím komerčních předplatných. Project Lightwell staví na iniciativách jako Anthropic Glasswing nebo OpenAI Trust Access for Cyber.
Open source 3D herní a simulační engine Open 3D Engine (O3DE) byl vydán v nové verzi 26.05. Podrobný přehled novinek v poznámkách k vydání.
Český stát by v budoucnu mohl provozovat vlastní alternativu ke komunikačním aplikacím typu WhatsApp, Signal, Telegram, Facebook Messenger a podobně. Cílem je zajistit bezpečnou datovou komunikaci pro stát a jeho důležité subjekty, jako jsou bezpečnostní složky, ministerstva a další organizace.
Už za týden, ve čtvrtek 4. června, se v Národní technické knihovně v pražských Dejvicích uskuteční další konference věnovaná tématům spojeným s IPv6 - Den IPv6. Program akce a registrační formulář jsou k dispozici na webu akce. Kapacita konference je omezená, proto organizátoři doporučují, aby se vážní zájemci přihlásili včas (k dnešnímu dni zbývá přibližně 30 volných míst). Konferenci Den IPv6 2026 organizují i letos společně sdružení CESNET, CZ.NIC a NIX.CZ.
Zařízení Steam Deck OLED bylo znovu naskladněno, ale vlivem rostoucích cen pamětí a úložišť má novou, vyšší cenovku. Steam Deck OLED 512 GB stojí nově 779 EUR (stál 569 EUR) a Steam Deck OLED 1 TB stojí 919 EUR (stál 679 EUR). Samotné zařízení se nijak nezměnilo a nové ceny tedy pouze odráží aktuální náklady na komponenty a další globální logistické výzvy, se kterými se potýká celá branže.
Český telekomunikační úřad zahajuje novou etapu využívání vysokofrekvenčního rádiového spektra v pásmu 26 GHz. Toto pásmo bude od 1. 7. 2026 otevřeno pro provoz moderních bezdrátových sítí, zejména sítí páté generace (5G), pevných bezdrátových přístupových sítí (FWA) a lokálních či průmyslových sítí určených například pro výrobní areály, logistická centra nebo technologické kampusy. Současně s otevřením pásma 26 GHz přistoupil ČTÚ ke zpřístupnění informací o využívání rádiových kmitočtů v tomto pásmu.
Logitech představil myš Signature Comfort Plus M850 L s polstrovanou opěrkou dlaně pro větší pohodlí a sadu s touto myší a klávesnicí s integrovanou opěrkou dlaní Signature Comfort Plus Combo MK880.
Gaël Duval se rozepsal o novinkách a plánech Murena a /e/OS. Počet uživatelů telefonů Murena a mobilního operačního systému /e/OS bez aplikací a služeb od Googlu se blíží 100 000. Ambicí je, aby se /e/OS stal třetí mobilní platformou v Evropě i na světě, s potenciálem dostat se i na PC. Blíží se vydání nové verze 4 s funkcemi zálohování a obnova, import e-mailů z Gmailu a rozpoznávání hlasu. Murena Workspace přinese videohovory, elektronický podpis a správu zařízení (MDM).
Dnes a zítra probíhá Ubuntu Summit 26.04. Na programu je řada zajímavých přednášek. Sledovat je lze na YouTube. Úvodní slovo měli Mark Shuttleworth a Jon Seager.
Máme tady server Primergy RX300S2 a v něm RAID5 řadič LSI 320-2E. Zapisovalo se na něj nějakých 50MB/s (XFS). Potom nám vyměnili MB a uživatelé si začali stěžovat na pomalost disku. Není divu, dosáhneme nejvýše 5MB/s. Chybová hlášení žádná. Něco se asi muselo špatně nastavit v rámci výměny MB. Neměl by někdo prosím myšlenku, co by to mohlo být? Uvnitř jsou SCSI disky 300MB a i ten RAID5 se tváří jako SCSI disk.
Dík to bylo vyčerpvaíjcí. Zkusím se podívat po novějším BIOSu, to se mi zdá dobrá stopa. Zkusím to s volbičkou irqpoll a když tak nějak zacvičím s ACPI. Podívám se, jestli je tam nějaký Event log.
Koukal jsem se do BIOSu toho RAIDu. Všechny disky se hlásí bez chyb. RAID tvrdí, že je OK. V logu z bootování mi to píše 6807.12 BogoMIPS . Já nevím co to znamená. Nic mi nebliká a nepiští. V messages žádná chyba.
Stalo se, že začaly nějak postupně odumírat filesystémy, vypadalo to na úplný rozpad. Dělo se to při větším zatížení diskovým provozem. Ale po rebootu byla všechna data na svém místě. V BIOSu RAIDu se dá nastavit kešovaný nebo přímý režim. Když jsem dal přímý, tyhle problémy vymizely. Udělal jsem /var/log jako zvláštní filesystém a zase zapnul kešovaný provoz. Rozpad opět nastal a v logu něco bylo, že se spouští nějaká patrola. RAID si vnitřně zřejmě dělal nějakou kontrolu nebo opravu. To stačilo servisní firmě, aby vyměnili MB. Po výměně nám to po hodině provozu zase padlo. Ale že jsem nevěděl co dál, jenom jsem to rebootoval a od té doby to už pár měsíců běží, kešovaně. Až uživatelé přišli na to, že je to nějak pomalý. Tak jsem se tím začal zabývat. Především jsem to zase přepnul na nekešovaný režim, ale rychlost se nezměnila.
Ten stroj je v záruce. Já vyzkouším co jsi mi poradil, pustím HW testy a budu znovu reklamovat. Každopádně děkuji za řadu pěkných tipů.
Některé adresáře tam byly ale nedalo se v nich udělat ls. V jiných se dalo, ale chyběly tam soubory. Některé soubory byly vidět pomocí ls ale nešly přečíst. Chybová hlášení byla jedině I/O error. SCSI chyby žádné. Filesystémy se postupně dělaly read-only, nakonec i / . Ono to / je taky na tom poli.
Podle mě takhle by se to chovalo, kdyby byl problém mezi raidem a keší. Po vypnutí keše to skutečně začalo fungovat. Ale firmware RAID řadiče je prý aktuální. Vyloudit tuto chybu uměl jenom jeden z uživatelů nějakým specifickým výpočtem. Ostatní výpočtáři neměli problém. Rozhodně nestačilo libovolné větší zatížení.
Nezapomeň že jsme vyměnili Mb i s RAID řadičem, on je integrovaný. to bychom museli mít dvě různé závady.
Jinak výměna 320-2E za holý HBA pro potřeby testování dává smysl i v tomto případě, protože Vám dá příležitost lépe si ohmatat SCSI sběrnici. Je možné, že RAID leccos skryje - chybové hlášky ze SCSI sběrnice se do syslogu hostitelského Linuxu dostanou zprostředkovaně přes z principu mírně dementní RAIDový firmware skoupý na slovo, kdežto od LSI HBA je to z první ruky.
Stačilo nastavit režim zápisu WRITEBACK, to znamená že pole přijme požadavek na diskovou operaci a potvrdí ho, aniž by čekalo na fyzické provedení zápisu. Je to vlastně riskantní, protože zápis se taky nemusí podařit a zapisující linux už se o tom nedozví. U obyčejního disku bych do toho nešel, ale tohle je diskové pole navíc obdařené baterií. Při poruše disku se to zapíše na ostatní disky a chybující disk bude vyřazen. I při výpadku elektřiny to baterka podrží, než se nadržené operace provedou. Takže to riziko snad není tak velké. Původně bylo WRITETHROUGH, to je ta bezpečná varianta.
Dále jsem nastavil režim čtení na READAHEAD, takže po provedení zadaného čtení si pole do keše připraví ještě následující kousek dat, neboť už tuší, že na ně brzy dojde. Původně tam bylo NORMAL.
Načež se nám pole zrychlilo na osminásobek a běhá zase jako dřív, jako před první výměnou motherboardu. Ono je to celé takhle: RAID řadič je integrovaný na MB. Servisní RAID data jsou v paměti toho řadiče a kopie na discích. Po výměně MB nový řadič servisní data neměl, tak si je vzal z disků. Ale optimalizační parametry na discích nebyly, tak tam nechal defaulty. Nový RAID řadič staré parametry skutečně nemohl znát. To spíš je mohl znát ten servisní technik. který nám MB vyměnil, žeano.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz