Svobodná historická realtimová strategie 0 A.D. (Wikipedie) byla vydána ve verzi 28 (0.28.0). Její kódový název je Boiorix. Představení novinek v poznámkách k vydání. Ke stažení také na Flathubu a Snapcraftu.
Multimediální server a user space API PipeWire (Wikipedie) poskytující PulseAudio, JACK, ALSA a GStreamer rozhraní byl vydán ve verzi 1.6.0 (Bluesky). Přehled novinek na GitLabu.
UBports, nadace a komunita kolem Ubuntu pro telefony a tablety Ubuntu Touch, vydala Ubuntu Touch 24.04-1.2 a 20.04 OTA-12.
Byla vydána (Mastodon, 𝕏) nová stabilní verze 2.0 otevřeného operačního systému pro chytré hodinky AsteroidOS (Wikipedie). Přehled novinek v oznámení o vydání a na YouTube.
WoWee je open-source klient pro MMORPG hru World of Warcraft, kompatibilní se základní verzí a rozšířeními The Burning Crusade a Wrath of the Lich King. Klient je napsaný v C++ a využívá vlastní OpenGL renderer, pro provoz vyžaduje modely, grafiku, hudbu, zvuky a další assety z originální kopie hry od Blizzardu. Zdrojový kód je na GitHubu, dostupný pod licencí MIT.
Byl představen ICT Supply Chain Security Toolbox, společný nezávazný rámec EU pro posuzování a snižování kybernetických bezpečnostních rizik v ICT dodavatelských řetězcích. Toolbox identifikuje možné rizikové scénáře ovlivňující ICT dodavatelské řetězce a na jejich podkladě nabízí koordinovaná doporučení k hodnocení a mitigaci rizik. Doporučení se dotýkají mj. podpory multi-vendor strategií a snižování závislostí na vysoce
… více »Nizozemský ministr obrany Gijs Tuinman prohlásil, že je možné stíhací letouny F-35 'jailbreaknout stejně jako iPhony', tedy upravit jejich software bez souhlasu USA nebo spolupráce s výrobcem Lockheed Martin. Tento výrok zazněl v rozhovoru na BNR Nieuwsradio, kde Tuinman naznačil, že evropské země by mohly potřebovat větší nezávislost na americké technologii. Jak by bylo jailbreak možné technicky provést pan ministr nijak nespecifikoval, nicméně je známé, že izraelské letectvo ve svých modifikovaných stíhačkách F-35 používá vlastní software.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 162 (pdf).
Sdružení CZ.NIC, správce české národní domény, zveřejnilo Domain Report za rok 2025 s klíčovými daty o vývoji domény .CZ. Na konci roku 2025 bylo v registru české národní domény celkem 1 515 860 s koncovkou .CZ. Průměrně bylo měsíčně zaregistrováno 16 222 domén, přičemž nejvíce registrací proběhlo v lednu (18 722) a nejméně pak v červnu (14 559). Podíl domén zabezpečených pomocí technologie DNSSEC se po několika letech stagnace výrazně
… více »Google představil telefon Pixel 10a. S funkci Satelitní SOS, která vás spojí se záchrannými složkami i v místech bez signálu Wi-Fi nebo mobilní sítě. Cena telefonu je od 13 290 Kč.
v poslední době to vídávám poměrně často, kill -9 nezabije proces ... jeden případ je, když mám namapovaný nějaký disk přes cifs a na něm otevřené soubory pro zápis a widlí server někdo zrestartuje, tak mi nejde ani odmountit adresář a ani zabít ty procesy s devítkou. druhý případ řeším aktuálně, např. cat malého txt souboru (4kB) zabírá 99% CPU a nejde zabít. První případ asi nevyřeším, ale co druhý ? Tipuju na vadnou paměť. Je pravda, že před aktualizací jádra a OS si nepamatuju, že by to dělalo. Zkusím to ještě se starým jádrem ale štve mě proces co nejde zabít a musím trapně linux server resetovat .... nějaký tip ? Dík
A tech 99% travi v userlandu nebo v jadru?
Kazdopadne ten prvni pripad je proces ve stavu neprerusitelneho cekani (to je mimochodem dobry argument pro kampan microsoftu misto tech volovin co tam maji ted. tuhle zalezitost ma windows naprosto nesrovnatelne lepe resenou). A to druhe bude zase sprajcnuti se v nejakem spinlocku toto jsem ovsem popravde jeste nevidel 
druhý případ řeším aktuálně, např. cat malého txt souboru (4kB) zabírá 99% CPU a nejde zabít.co zkusit strace co to dela?
[root@node2 ~]# strace -p 10388
Process 10388 attached - interrupt to quit
a nic víc nebo mám pustit strace s dalšími parametry ? Tak nějak to pořád vidím na chybný HW, ale popravdě tohle je jiný stroj (už druhý) se stejnou chybou ve stejném kernelu.
Nepravděpodobné, ale zkuste -f nebo -F.
Pokud ale strace nic nenašel, tak cat žádné nové služby systému nevolá. Takže se zacyklil.
Takže v jakém je stavu podle ps? Jestli S nebo D, tak zůstal viset v jádře. Pokud R, tak v uživatelském prostoru. Pak je dobré zkusit odtrasovat běh samotných instrukcí procesu. Třeba pustit gdb -p $(pidof cat) a podívat pomocí backtrace, v jaké funkci se točí.
no tak momentálně mi tam nevisí ani cat ani grep , ale zjištění statusu databáze (nějaký proprietalní closedsource sw) a visí ve stavu R. kill -9 samozřejmě nic neudělá
Pokud je vadna pamet, tak nema smysl vubec nic dalsiho resit! Pro jistotu to chce otestovat pamet treba pres noc. V pripade zajmu bych vyhrabal memcheck.
Kazdopadne jednim z dobrych testu pameti je kompilace kernelu nebo wine. Pokud se zkompiluji dobre, tak je pamet versinou v poradku.
to vím, jde však o servery v clusteru a není možné si s nima moc hrát. Navíc třeba s takovým memtestem na značkových serverech nemívám moc dobrou zkušenost (sám nevím proč), na běžných PC mi běží memtest dobře, ale na některých servech detekuje buď neexistující chyby nebo jede moc zdechle. Do odbou serverů se přidávala paměť, aktualizoval jsem OS, vanillu kernel a oba mají podobné potíže.
chápu,ale dělá to od doby, co jsem přidal paměť a aktualizoval OS a kernel. Nechce se mi věřit, že by byla vadná paměť na obou, tak to momentálně vidím nejvíc na kernel. Než testovat paměť celou noc, tak je pro mě jednodušší zkusit staré jádro. Ona se ta chyba projeví do dvou dnů spolehlivě... Navíc ty značkové RAMky made in HP byly drsně drahé a údajně testované :D
Prave naopak. Pokud je vadna pamet, tak dochazi k naprosto nekontrolovatelnym havariim a muze dojit i ke zdrate dat s disku.
tak se starším jádrem mi to sice nedělá, ale zase se mi objevuje kernel panic. Zkoušel jsem přes noc memtest a bez chyby. Tak jsem celkem v koncích
as far as I know : server bezel bez potizi na 2.6.24.3, pak jsem do nej pridal RAM, sitovou kartu a dva SAS disky. Nejsem si jist, jestli to zlobi presne od te doby, skoro bych rekl, ze ne. Moje posledni akce byla yum update a pak build 2.6.31 vanilly + drbd. Pak zacly problemy s procesy, co nesly zabit. V puvodnim kernelu 2.6.24.3 se sice tyto procesy nevyskytuji, nicmene se mi objevuje kernel panic, pravda ne tak casto jako ty nezabijitelne procesy ve 2.6.31
Tiskni
Sdílej: