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č.
Zdravím,
už delší dobu se potýkám s problémem s MySQL databází, která dovedete běžet na serveru (Debian) nonstop třeba půl roku, ale pak přijde jeden nutný reboot serveru, po kterém do jednoho až třech dnů databáze spadne. Vypadá to tak, že load vzroste (ale někdy ne), databáze neodpovídá, ale zbytek běží normálně, apache atp. Při snaze mysql restartovat to vythuhne při jejím vypínání. Nezbyde tak nic jiného než restart celého serveru. Ten většinou pomohl a pak už to stabilně běželo "donekonečna" než jsem učinil časem další restart serveru.
Nějak jsem nedokázal přijít na to co by to mohlo dělat (a myslím, že ani v lozích nic nebylo). Proto jsem je vypnul. Někdo říkal, že to může být dokonce chyba logů. Navíc mi tak poklesla zátež.
Jenže teď se mi přihodila nemilá věc. Po nutném rebootu serveru jsem očekával, kdy to zase padne. A padlo... 2 dni na to. Tak jsem rebootoval server, jenže ouha. MySQL nenaběhlo a load na 30ti. Nechal jsem to 10 minut a stále nic. Opět nepomohlo nic jiného než reboot celého serveru, po kterém to už naběhlo úplně normálně.
Jenže tenhle druhý reboot mě vrátil do nechtěné smyčky a po 3 dnech to padlo zase. Opět pomohl až druhý reboot a opět čekám, kdy to zase klekne.
Teď ale co s tím. To první nenaskočení databáze po restartu serveru může být nejaká kontrola databáze po pádu a násilném restartu. Tuším, že pokud tu kontrolu přeruším dalším rebootem, příště se nespustí hned po startu, ale v záhadně načasovaném období jednoho až třech dnů (v cronu nic není). Bohužel během této kontroly databáze neběží a probíhat může taky hodinu nebo 2 a protože si to samozřejmě nenačasuje na noc, nemůžu si dovolit ji doběhnout kvůli dostupnosti serveru.
To s tou kontrolou je ale jen domněnka, možná je to něco úplně jiného. Nemáte někdo tušení co? Přemýšlím o opětovném zapnutí logů. Ale jestli mě pamět neklame, tak jsem v nich loni opravdu nic nenašel a jejich zapnutím bych snížil výkon už tak celkem vytíženého serveru na třeba i 3 dny. Když nebude na výběr, učiním tak, ale než to udělám. Nemáte někdo podobnou zkušenost nebo tušení v čem by mohl být problém?
Předem díky za případné podnětné reakce.
No nebudu se přít, moc toho o tom nevím, ale všiml jsem si, že dokonce v samotném my.cnf je uvedeno:
# Be aware that this log type is a performance killer.
#log = /var/log/mysql/mysql.log
)
Na tom něco bude :) jenže jak hledám tak hledám, pořád nemůžu najít jak bych ten log zapnul přes nějakej konfigurační soubor, aniž bych musel měnit parametry při spouštění mysql. Výstupem tuším bude /var/log/mysql.err, který je teď prázdný. Přijde mi to jako naprosto nejzákladnější záležitost, na kterou se po netu bude válet miliony návodů a ono nic.
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz