Lennart Poettering se na Mastodonu rozepsal o novince v systemd, na které pracuje: systemd bude umět nabootovat z obrazu disku staženého pomocí HTTP v rámci initrd.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2025.2. Nově lze zálohovat také na Google Drive a Microsoft OneDrive.
V kinech aktuálně běží animovaný film Kočičí odysea, v originálu Flow, (Wikipedie) vytvořený v Blenderu. Film získal řadu ocenění a má dvě nominace na Oscary 2025. Na ČSFD má 80 %. Režisérem je Gints Zilbalodis. Rozhovor s režisérem na stránkách Blenderu.
Oficiálně byla vydána (Mastodon, 𝕏) třetí RC verze GIMPu 3.0. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu. GIMP je nově k dispozici také ve formátu AppImage.
Nejnovějším projektem Blender Studia je herní projekt DogWalk. Cílem projektu je prozkoumat možnosti a vylepšit spolupráci Blenderu s herním enginem Godot a vytvořit jednoduchou hru. Jde o jejich druhý herní projekt. Prvním byla hra Yo Frankie! (projekt Apricot) postavená na již nevyvíjeném Blender Game Enginu.
Byla vydána verze 0.83 telnet a ssh klienta PuTTY. Podrobnosti v přehledu nových vlastností a oprav chyb a Change Logu. Vypíchnuta je podpora výměny klíčů pomocí postkvantového algoritmus ML-KEM.
Hector "marcan" Martin z Asahi Linuxu skončil jako upstream vývojář linuxového jádra. Štafetu po něm převzal Janne Grunau z Asahi Linuxu.
PlayStation Network (PSN) má již několik hodin, vlastně celou sobotu, masivní výpadek (Stav služby PSN, X).
Vývojáři open source storage platformy TrueNAS oznámili, že s verzí 25.04 s kódovým názvem Fangtooth končí TrueNAS CORE postavený na FreeBSD a TrueNAS SCALE postavený na Linuxu. Jejich společným pokračováním bude TrueNAS Community Edition postavený na Linuxu.
Mapy Google dnes slaví 20 let. Spuštěny byly 8. února 2005. Svět se přesunul od papírových map k digitálním. A ke Street View, Live View, Immersive View, …
Řešení dotazu:
[mysqld] key_buffer = 16K max_allowed_packet = 1M table_cache = 4 sort_buffer_size = 64K read_buffer_size = 256K read_rnd_buffer_size = 256K net_buffer_length = 2K thread_stack = 64K query_cache_limit = 1M query_cache_size = 8M innodb_buffer_pool_size = 8M innodb_additional_mem_pool_size = 1M innodb_log_file_size = 5M [isamchk] key_buffer = 8M sort_buffer_size = 8M [myisamchk] key_buffer = 8M sort_buffer_size = 8MVychází to z OpenSuse 'my-small.cnf' a zkušeností z vlastním serverem, který měl 96Mb Ram :), bohužel již jej nemám, a nemám ten přesný konfigurák z něj…
innodb_buffer_pool_size = 16M innodb_additional_mem_pool_size = 2MJak to dopadlo ?
Páni, 12MB ram jo?
Jasně, rejpu, ale nechceme přeci aby se tu šířili dezinformace.
Samozřejmě jsem pochopil co autor chtěl říci, jde o to že tuhle diskusi si přečte mnoho lidí, bez mého trapného příspěvku z kterého pramení toto vlákno by si spousta lidí spojila velikost operační paměti s "Mb" a mě už docela nebaví pořát dokola lidem vysvětlovat rozdíl mezi Mb a MB.
Naopak, díky našemu vláknu si každý spojí operační paměť s "MB" a síťový provoz s "Mb", tedy nejenže pár dalších lidí bude vědět něco o jednotkách, ale snad to budou i šířit dál, tedy, naše trapné vlákno obecné it gramotnosti pomůže mnohem více než by kdo čekal.
Naopak, díky našemu vláknu si každý spojí operační paměť s "MB" a síťový provoz s "Mb", tedy nejenže pár dalších lidí bude vědět něco o jednotkách, ale snad to budou i šířit dál, tedy, naše trapné vlákno obecné it gramotnosti pomůže mnohem více než by kdo čekal.
I tak se to dá brát, souhlas
'bit'
:1 kbit/s = 1000 bit/s 1 Kibit/s = 1024 bit/s x 1 kB = 1000 B 1 KB = 1024 BA je to právě kvůli záměně B/b :)
KiB, MiB.. byly sic vytvořeny aby v tom udělali pořádek, ale ve výsledku v tom udělali ještě větší bordel, používat to je myslím úplná blbost (osobní názor).
Navíc, jak na to tak koukám, tak oni tim že chtěli vytvořit nový standart tak jiný porušili, to je k smíchu.
1 kbit/s = 1000 bit/s 1 Kibit/s = 1024 bit/s x 1 kB = 1000 B 1 KiB = 1024 BUž jsem radši dnes s jednotkami skončil, ještě použiji jednu odpoledne: „koupím si 2ℓ burčáku“ a konec, bo mi to nějak nejde.
Debian /etc/mysql/my.cnf
'/usr/share/mysql'
na OpenSuse jsou 3 ks předpřipravených konfiguráků small, medium a huge, kde je to „nějak“ v základu nastaveno, když to nechcete řešit nebo nemáte zkušenosti, je to dobrý výchozí bod (nastavení InnoDB, jestli se nepletu, tam je zakomentováno a ve všech souborech je identické).je to dobrý výchozí bod (nastavení InnoDB, jestli se nepletu, tam je zakomentováno a ve všech souborech je identické).
Tak tak, ještě by tam měl být konf. my-innodb-heavy-4G.cnf s nastaveným InnoDB.
Nastavit to pro silnejsi server jiz neni se znaloptmi matematiky zakladni skoly problem.
Nastavit to pro silnější server není otázkou matematiky, je to otázkou znalosti té DB a jejího použití. Vůbec to není o vynásobení všech parametrů nějakou konstantou ale o poměrně složitém vyvážení všech parametrů. U MySQL je to zvlášť těžké v případě, že se používá více tabulkových enginů.
Jistě, ale někdo kdo hledá přednastavené konfigurační soubory určitě ony znalosti databázového serveru (či jednotlivých enginů) prostě nemá, nebo s nastavováním nechce ztrácet čas (což opět hovoří o jeho neznalosti).
No to je složité. Pokud to někdo nastaví čistě matematicky, tak snadno skončí s DB, která nejenže nemá žádný výkon, ale ještě k tomu žere příliš mnoho paměti.
Pro pomoc s nastavením výkonových parametrů MySQL vřele doporučuji mysqltuner.pl nebo podobný MySQL Tuning Primer.
Pochopitelně nic z toho nezachrání blbě navržené DB schema.
Souhlasím že nastavovat to přímo úměrně vůči operační paměti není úplně ideální, ale bez potřebných znalostí k správnému nastavení jak enginů tak samotného serveru je to krom dotazu v diskusi nejlepší řešení.
Tiskni
Sdílej: