Planeta OpenAlt

MeshCore jako (nekompatibilní) alternativa k Meshtastic? Jak jej nastavit, abyste si mohli psát?

11.
dubna
chiptron.cz
MeshCore jako alternativa k populární off-grid textové komunikaci Meshtastic je nyní už i v Česku. Během velmi krátké chvíle se vytvořila silná komunita, která pracuje na vylepšení pokrytí právě sítí MeshCore pracující pomocí rádií s podporou LoRa. Chcete se zapojit? "Jak na to" se dozvíte v tomto článku - jak funguje, rozdíly mezi MeshCore a Meshtastic, podporovaný hardware a jak jej v Česku nastavit. Aktualizace1! Nový preset pro Českou republiku. Aktualizace2! Nový firmware pro Repeatery, přechod z 1B na 2B síť.

📖 Přečíst celý článek →

celý članek

Framework Laptop 13 (AMD AI 300) - zkušenosti

11.
dubna
Jakub Cabal

Zhruba před půl rokem jsem dostal nový pracovní notebook. Už nějakou dobu jsem pokukoval po počítačích značky Framework, takže když se objevila možnost výběru nového pracovního notebooku, zvolil jsem právě Framework Laptop 13 DIY (AMD Ryzen™ AI 300 Series). Kdo by také nechtěl notebook, který si můžete sestavit sami a v případě potřeby ho snadno opravit nebo například vyměnit porty.

framework-laptop-13

Tohle je moje konfigurace Framework Laptop 13:

  • System: Ryzen™ AI 5 340
  • Display: 2.8K Display
  • Memory: DDR5-5600 - 32GB (2 x 16GB)
  • Storage: WD_BLACK™ SN7100 NVMe™ - M.2 2280 - 500GB
  • Operating System: None
  • Bezel: Black
  • Keyboard: Czech/Slovak (2nd Gen)
  • Power Adapter: Power Adapter - 60W - EU
  • Expansion Cards: 2x USB-C (Aluminum), 1x USB-A, 1x HDMI (3rd Gen)

Den po objednání (konec října 2025) odeslal výrobce balík s notebookem z Taiwanu a během tří dnů dorazil do ČR. Vyšlo to tehdy akorát na pátek, takže jsem měl celý víkend na sestavení a instalaci nového notebooku. Jako obvykle jsem zvolil operační systém Fedora Linux (Workstation). Sestavení a instalace notebooku byly otázkou pár hodin a pak už jsem ho mohl vesele používat a sbírat zkušenosti.

Zkušenosti po 5 měsících

Za těch pár měsíců, co Framework Laptop 13 používám, můžu konstatovat, že s Fedorou 43 funguje perfektně. Všechny komponenty fungují pod Linuxem dobře, a to i včetně čtečky otisků prstů. Jelikož používám zašifrovaný disk, využil jsem TPM2 čip pro automatické odemykání šifrovaného oddílu podle tohoto detailního komunitního návodu. Ve zkratce stačí zavolat tyto dva příkazy:

sudo systemd-cryptenroll --wipe-slot tpm2 --tpm2-device auto --tpm2-pcrs "1+3+5+7+11+12+14+15" /dev/nvme0n1p3
sudo dracut -f

Původně jsem se obával spolehlivosti vestavěné WiFi karty Mediatek MT7925 (RZ717) pod Linuxem, protože řada uživatelů reportovala problémy se stabilitou. Možná jsem měl jen štěstí (nebo novější kernel), ale za celou dobu používání jsem nenarazil na jediný problém s WiFi.

Celkové zpracování Framework Laptop 13 je velmi dobré. Nechybí česká klávesnice včetně podsvícení. Velikost (15,85 mm x 296,63 mm x 228,98 mm) a váha (1,3 kg) nikoho neomezí při častém přenášení. Moje konfigurace obsahuje sice jen základní model procesoru, ale šestijádrový AMD Ryzen AI 5 340 běžící na frekvenci až 4,8 GHz má výkonu dostatek.

framework-laptop-13-btop

Ovšem to nejlepší je displej: ideální úhlopříčka 13,5" s netradičním poměrem stran 3:2 a obnovovací frekvencí 120 Hz. Jemné rozlišení 2880x1920 px umožňuje fungovat v režimu HiDPI se škálováním na 200 %. Kéž by se takové displeje staly standardem.

Ale nic není dokonalé a také tento Framework Laptop 13 má slabší stránky. Oproti mému předchozímu Lenovu ThinkPad T480s (Intel Core i7-8550U) pozoruji výrazně větší zahřívání celého notebooku a s tím související vyšší hlučnost chlazení. Také výdrž baterie není na dnešní dobu žádný zázrak – Framework Laptop 13 v průměru vydrží cca 7 h na jedno nabití.

framework-laptop-13-fastfetch

Problémy, které jsem pozoroval

Zde uvádím popis několika problémů, které jsem při používání Framework Laptop 13 zaznamenal. Většina z nich má poměrně snadné řešení a nejspíš se projevuje jen na Linuxu. Třeba vám to nějak pomůže.

Chybné reportování vybité baterie

Tento problém se objevuje jen velmi zřídka (obvykle tak jednou za měsíc) a zatím zřejmě nemá řešení. Zničehonic začne systém hlásit vybitou baterii (0 %), přestože před okamžikem byl stav například 77 %. Téměř vždy se během několika vteřin systém sám zotaví a začne hlásit správný stav baterie. Nicméně jednou už se mi stalo, že tento chybný stav trval déle a notebook se začal vypínat. Stejný problém reportovalo více uživatelů.

Nefunkční digitální mikrofon

Digitální mikrofon pod Linuxem podle všeho vůbec nefunguje a je potřeba používat analogovou verzi. Pro méně komplikovaný život je nejlepší rovnou zakázat jeho ovladač. Vytvořte soubor /etc/modprobe.d/blacklist-snd_soc_dmic.conf s následujícím obsahem:

blacklist snd_soc_dmic
blacklist snd_acp_legacy_mach
blacklist snd_acp_mac

Občasné problikávání obrazovky ve Firefoxu

Narazil jsem také na grafický bug s problikávající obrazovkou, který se projevuje při pohybu kurzoru na některých webech (například web HN) ve Firefoxu. Problém lze vyřešit vložením MUTTER_DEBUG_DISABLE_HW_CURSORS=1 do souboru /etc/environment a restartováním.

framework-laptop-13-top

Závěr

Přestože Framework Laptop 13 není dokonalý a má své chyby, dobře se mi na něm pracuje a jsem s ním spokojený. Pokud jste technologický nadšenec nebo uživatel Linuxu, bez debat vám ho doporučím. Nicméně Framework Laptop 13 nepatří mezi nejlevnější počítače a pokud člověk nepotřebuje nějakou jeho speciální vlastnost (třeba zmíněný specifický displej), dává velký smysl uvažovat o alternativách. Kdybych měl dnes koupit dobrý počítač pro běžného uživatele za dobrou cenu, koupil bych repasovaný, pár let starý Lenovo ThinkPad vyšší kategorie. S tím člověk udělá ještě spoustu parády a stojí to pár korun.

Líbil se ti tento text a chceš mě podpořit? Kup mi Kofolu! Díky.

celý članek

Jarní Akademie Stronger Roots: Jak cíleně posilovat komunity a inspirovat se navzájem

10.
dubna
Nadace OSF

Srdečně vás zveme na další cyklus Akademie Stronger Roots. Na webinářích společně prozkoumáme nové aspekty budování komunity příznivců a budeme sdílet zkušenosti z praxe různých organizací občanské společnosti. 

Kultura jako magnet: Jak budovat komunitu kolem nápadu 

🗓 Termín: úterý 28. dubna 2026, 15:00 – 17:00, ZOOM

Kulturní organizace mají specifickou výhodu, kterou jsou emoce a kreativní obsah. Jak proměnit nárazového návštěvníka v aktivního člena komunity, který se podílí na rozvoji místa nebo regionu? Hlavním tématem tohoto webináře bude budování komunity kolem kulturního tématu a organizace. Specifika fundraisingu s tématem kultury a zapojování dobrovolníků, čím se to liší a co se osvědčilo. Jak využít kulturní program jako nástroj pro networking a jaké aktivity nejlépe fungují pro dlouhodobé udržení zájmu.

Na koho se můžete těšit?

  • Broumov 2028+ – Anna Smékalová – Jak do kulturních aktivit zahrnout jednotlivé cílové skupiny a vytvořit z nich „spolumajitele“ projektů. Jak přemýšlet nad udržitelnou prací s komunitou.
  • BalCan CrossOver – Jakub Novosad a Tereza Mádlová – Vášeň a vztahy jako klíč k síťování a budování komunity. Jak se buduje komunita kolem kolem festivalu zaměřeného na současnou balkánskou kulturu a kinematografii.
  • a další

Na webinář se prosím registrujte nejpozději do 26. dubna 2026 na odkaze níže. 

Chci se registrovat na webinář

 

Komunitní prostory a jejich využití: Když místo tvoří vztahy

🗓 Termín: úterý 26. května 2026, 10:00 – 12:00, ZOOM

Fyzický prostor není jen prázdnou kulisou, ale je katalyzátorem setkávání. Podíváme se na to, jak architektura, káva nebo knihy pomáhají bořit bariéry mezi lidmi. Hlavní téma bude využití prostoru a jak zařídit, aby se lidé u vás nebáli mluvit a tvořit společně. Ukážeme si, že k vybudování živého sousedství nestačí jen otevřít dveře, ale je třeba vědomě pracovat s atmosférou a komunitou.

Na koho se můžete těšit?

  • Sdružení Neratov – Antonín Nekvinda
  • Stará Jedáleň – Anna Karako (SK)
  • Komunitní centrum a zahrada Kotlaska – Kateřina Jirová

Na webinář se prosím registrujte nejpozději do 24. května 2026 na odkazu níže.

Chci se registrovat na webinář

 

Komunita v sociálních službách: Více než jen klientela

🗓 Termín: úterý 9. června 2026, 10:00 – 12:00, ZOOM

Tento webinář se zaměří na to, jak v sociálních službách překročit stín „poskytovatel–klient“ a budovat ekosystém kolem rodin, sousedů a podporovatelů. Hlavní téma bude změna mindsetu u vedení i týmu. Jak přejít od „my jim pomáháme“ k „tvoříme to společně“.

Na koho se můžete například těšit?

  • Sue Ryder – Monika Havlová
  • EUROTOPIA.CZ – Petra Večerková a Lucie Veverková
  • a další

Na webinář se prosím registrujte nejpozději do 4. června 2026 na odkazu níže.  

Chci se registrovat na webinář

Program Stronger Roots financuje Evropská unie. Vyjádřené názory a stanoviska jsou však výlučně názory autorů a autorek a nemusí nutně odrážet názory Evropské unie nebo Evropské agentury pro vzdělávání a kulturu (EACEA). Evropská unie ani EACEA za ně nenesou žádnou odpovědnost.

celý članek

Trh online reklamy stabilně roste: v roce 2025 o 10,6 % na 70,7 miliard korun

09.
dubna
Sdružení pro internetový rozvoj

Tisková zpráva Praha, 9. dubna 2026 – Online reklama v roce 2025 dosáhla téměř 71 miliard korun, což představuje meziroční nárůst o 10,6 %. Rostly všechny formy online reklamy – display reklama (+10,7 %), reklama ve vyhledávání (+10 %) i katalogy a řádková inzerce (+11,4 %). Odhad růstu pro rok 2026 je 7,4 %. Vyplývá to výzkumu inzertních výkonů internetové reklamy, který pro Sdružení pro...

Zdroj

celý članek

Interview ve Studiu ČT24 ke kompromitaci SOHO routerů TP-Link ze strany APT28

08.
dubna
Jan Kopriva

Dnes odpoledne jsem byl pozván do vysílání Studia ČT 24, kde jsem odpovídal na otázky týkající se aktivit APT28 zaměřených na kompromitaci SOHO routerů značky TP-Link, které se dle dostupných informací dotkly i České republiky. Záznam z vysílání Studia ČT24 najdete v případě zájmu na tomto odkazu - celý záznam diskuzí výše zmíněného tématu začíná…

Studio ČT24

celý članek

Digitální mlha - Ep#05 - Stačí npm install a máš malware. Axios útok, Chat Control a státní operace

07.
dubna
Jan Kopriva

Se začátkem měsíce tu máme již tradičně i novou epizodu podcastu Digitální Mlha, který připravuje CZECH CYBER TV ve spolupráci s Nettles Consulting. Najít jí můžete na YouTube a podíváme se v ní mj. na útok s pomocí dodavatelského řetězce s pomocí kompromitace balíčků HTTP klientu Axios, policejní zásah proti phishingové platformě Tycoon2FA, kybernetické útoky v souvislosti s vojenským konfliktem mezi USA a Íránem i řadu dalších témat…

celý članek

Potvrzeno: Průša bude zdražovat. Za Core One L si připlatíte 200 USD.

03.
dubna
chiptron.cz
Že na poli 3D tisku probíhá cenová válka není nic nového. Všichni se snaží prodávat co nejlevněji při zachování kvality. Abychom byli svědky, že 3D tiskárna významně zdraží, bývá velmi velmi neobvyklé. Tuhle otázku ale teď vyvolal jeden nevinný tweet navíc odkazující na dánský e-shop. Prusa Core One L by měl zvýšit cenu o 250 USD. Je to ale pravda? Aktualizace: Vyšší cena za Prusa Core One L potvrzena. Cena se zvýší o 200 USD.

📖 Přečíst celý článek →

celý članek

Linux kernel contributions 6.7 → 7.0-rc6

03.
dubna
David Heidelberg


David Heidelberg


76
Commits authored
30
Signed off
27
Reviewed
12
Tested
7
Bugs reported
155
Total touches

The bulk of the work centres on the Snapdragon 845 (SDM845) platform — bringing mainline Linux closer to fully supporting everyday phones like the OnePlus 6/6T, Xiaomi Mi MIX 2S, SHIFT6mq, and the Google Pixel 3 lineup.

Areas of work — click any card for details
SDM845 devices ~22 commits
Device-tree expansions for OnePlus 6/6T, Pixel 3/3XL, Xiaomi Mi MIX 2S, Pocophone F1, SHIFT6mq, and Samsung Galaxy S9.
OnePlusPixel 3XiaomiSHIFT
close ✕
  • Added full DTS support for Google Pixel 3 and Pixel 3 XL
  • ath10k WiFi calibration data for OnePlus, beryllium, axolotl
  • Framebuffer, panel pinctrl, TE GPIO, and regulator fixes for OnePlus
  • Firmware path updates across SDM845 boards
  • Guard pages for the rmtfs memory region
  • SLPI sensor DSP enablement on Xiaomi Pocophone F1
  • Notification LED for OnePlus 6 (enchilada)
  • Use shared msm-id definitions across SDM845 DTS files
Display panels ~18 commits
Major refactoring of the sofef00 and sw43408 panel drivers, plus a brand-new S6E3FC2X01 driver for the OnePlus 6T AMOLED.
sofef00sw43408S6E3FC2X01drm/panel
close ✕
  • New Samsung S6E3FC2X01 driver (AMS641RW — OnePlus 6T panel)
  • sofef00: non-continuous mode, video burst, LPM always-on, regulator handling, 50% initial brightness
  • sofef00: introduced panel-name-aware compatible string
  • sofef00: split enable/disable command sequences for clarity
  • sw43408: devm regulator bulk, removed manual unprepare, separated reset sequence
  • sw43408: introduced LH546WF1-ED01 panel compatible
  • DT bindings for SOFEF00 converted to standalone YAML
IIO light sensors ~14 commits
Deep cleanup of the Dyna Image AL3010, AL3320a, and AL3000a ambient-light sensor drivers — regmap, error handling, code structure.
AL3010AL3320aAL3000aregmap
close ✕
  • Implemented regmap support in both AL3010 and AL3320a
  • Fixed error handling paths in probe functions across all three
  • Split set_pwr into set_pwr_on / set_pwr_off for clarity
  • Removed DRV_NAME definitions (use module name instead)
  • Switched to unsigned int for array indexing
  • Improved error reporting with dev_err_probe()
  • Abstracted device references in probe functions
Device-tree bindings ~12 commits
Converting legacy .txt bindings to YAML schemas, adding new generic schemas, and cross-platform DTS fixes (Tegra, Freescale, Rockchip, Marvell).
YAMLdt-schemawirelesshwmon
close ✕
  • Added generic wireless-controller.yaml — used by qcom,wcnss, silabs,wfx, bcm4329-fmac
  • Added network-class schema for mac-address properties
  • Converted msm,iommu-v0 to YAML
  • Converted ad5820 camera focus actuator to YAML
  • Converted gpio-fan hwmon binding to YAML
  • Documented Tegra Nyan boards, fixed Freescale TMU calibration schema
  • GPIO-fan matrix fixes across Rockchip, i.MX8, and Marvell DTS
  • Idle-state and OPP binding cleanup for ARM Qualcomm targets
Camera subsystem ~6 commits
Qualcomm CAMSS improvements, C-PHY lane math fix in the CCS sensor driver, and better power-domain naming for SDM845.
CAMSSCCSC-PHYmedia
close ✕
  • CCS driver: fixed C-PHY lane count in clock frequency calculation
  • CAMSS: added named power-domain support for SDM845
  • CAMSS: documented the csiphy_lanes_cfg structure
  • Corrected camss supply description in DT bindings
  • PHY info can now be obtained from OF endpoint (documentation)
Older Qualcomm & misc ~8 commits
LG Nexus 4 initial DTS, APQ8064 WiFi, MSM8960/MSM8916 fixes, Nokia N900 cleanup, x86 Kconfig documentation tidy-ups.
Nexus 4MSM8960x86ALSA
close ✕
  • Initial DTS for LG Nexus 4 (APQ8064 / msm8960-based)
  • Enabled WiFi on APQ8064 LG Nexus 4
  • MSM8960: corrected memory base, dropped duplicate timer clock frequency
  • MSM8916: idle-state compatible fix
  • Nokia N900: removed useless io-channel-cells property
  • ALSA: stopped building obsolete API
  • x86 Kconfig: documented CONFIG_PCI_MMCONFIG, CNB20LE quirk, SPARSEMEM, glibc date
  • Reported and triggered reverts of USB gadget NCM regression series

155 total contributions across Linux 6.7 through 7.0-rc6, with 76 commits fully authored. The work breaks down into a few clear stories:

The Snapdragon 845 marathon. The heaviest lifting is enabling mainline Linux on real consumer hardware. The Google Pixel 3 and Pixel 3 XL got full device-tree support from scratch. OnePlus 6/6T gained proper display pinctrl, panel regulators, a framebuffer, a notification LED, and WiFi calibration. Similar treatment went to the Xiaomi Mi MIX 2S, Pocophone F1, SHIFT6mq, and Samsung Galaxy S9.

Display driver overhaul. Two panel drivers — sofef00 (OnePlus 6 display) and sw43408 — were significantly refactored: cleaner regulator handling, split command sequences, better compatible strings, and a proper reset function. On top of that, a brand-new S6E3FC2X01 driver landed for the OnePlus 6T's AMOLED panel.

IIO light sensor cleanup. The Dyna Image AL3010, AL3320a, and AL3000a drivers got a thorough polish — regmap migration, better error handling with dev_err_probe, splitting the power toggle into on/off helpers, and removing leftover DRV_NAME definitions.

Device-tree schema work. A generic wireless-controller.yaml was introduced and adopted by three wireless drivers. Several old .txt bindings (ad5820, gpio-fan, iommu-v0) were converted to proper YAML schemas, and cross-platform DTS bugs were fixed across Rockchip, i.MX8, Marvell, and Freescale targets.

Bug hunting. Seven reported bugs, including triggering a revert series of USB gadget NCM regressions that had broken Ethernet-over-USB functionality.


Authored (76):

Signed-off-by (30):

Co-developed-by (3):

Reviewed-by (27):

Tested-by (12):

Reported-by (7):

celý članek

Aktualizace: Raspberry Pi už podruhé zdražuje. Poprvé až o 20%. Kvůli ceně RAM pamětí.

01.
dubna
chiptron.cz
Jedna krize za druhou, nedostatek kondenzátorů, součástek, cena surovin a logistické problémy a teď tu máme pro změnu krizi plynoucí z nedostatku RAM pamětí. Cena RAM pamětí do osobních počítačů se během pár měsíců vyšplhala na dvojnásobek. A samozřejmě se to dotýká dalších produktů, které RAM paměti mají. Třeba jednodeskové počítače Raspberry Pi. Výrobce ohlásil zdražení až o 20%. Aktualizace2: Raspberry Pi 4 a 5 bude používat RAM paměti z Číny. Aktualizace3: Raspberry Pi 4 se 3 GB RAM. A opět další zdražení.

📖 Přečíst celý článek →

celý članek

VitruvianOS pilot release

30.
března
ALT-F4

Světlo světa spatřil nový operační systém nazvaný VitruvianOS, jehož pilotní verze 0.3.0 byla v minulém týdnu vydána pro veřejnost. Systém je sice založen na jádře Linux a využívá i některé linuxové knihovny a komponenty, ale tím jeho vztah k systémům se stejným jádrem končí. Vše nad úrovní samotného základu systému je totiž vyvíjeno samostatně a silně inspirováno systémem BeOS či Haiku, včetně toho, že systém bude v budoucnu s těmito svými předobrazy kompatibilní na úrovni API.

Již tato raná verze obsahuje vlastní kernelové moduly, které do systému zavádí například real-time latence, interface mapující systémové zprávy BeOS na odpovídající volání v Linuxu, vlastní správu zařízení či monitoring souborových systémů. Tato sada modulů je nazvána Nexus a ve finálním stavu by měla umožnit překlad aplikací pro BeOS/Haiku ze zdrojového kódu bez dalších úprav.

Systém má i zcela vlastní grafické rozhraní, které není založeno ani na X11 ani na Waylandu, ale jeho předobrazem je (opět) BeOS/Haiku.

Hlavní vývojář, Dario Casalinuovo, na projektu pracuje od roku 2019 a během uplynulé doby jej několikrát od základu přepisoval. Aktuálně vydaná verze, zveřejněná pod hybridní licencí GPL/MIT, je zatím relativně nestabilní, velmi nedodělaná a není určena k běžnému použití. Předpokládá se brzká opravná verze 0.3.1 a  u verze 0.3.2 bude hlavním cílem, aby systém bylo možné sestavit v něm samotném. 

Zdroje:

A proč ne? Linuxové jádro vyřeší podporu hardware tempem, kterým jí nemá Haiku šanci řešit a zbytek bude v podstatě stejný. Tedy samozřejmě až bude Nexus a GUI na stejné úrovni stability, jako je po dvaceti letech vývoje Haiku.

celý članek

Desatero pro začínající specialisty na kybernetickou bezpečnost

27.
března
Jan Kopriva

Čas od času mě nějaký juniorní bezpečnostní specialista, nebo člověk, který by chtěl do kybernetické bezpečnosti teprve profesně proniknout, požádá o pár rad „do začátku“. Technická specifika mých doporučení se pochopitelně liší případ od případu s ohledem na zájmy či plány konkrétní osoby, nicméně neb některá obecnější doporučení a myšlenky zmiňuji těmto lidem opakovaně, a neb jde dle mého o něco, co se může potenciálně hodit v podstatě každému juniornímu „bezpečákovi“, rozhodl jsem se dát dohromady pár myšlenek, které jsou z mého pohledu podstatné pro smysluplné, efektivní a spokojené profesní působení v kybernetické bezpečnosti.

Níže tedy najdete 10 doporučení (+ jedno dodatečné, abych udělal radost fanouškům skupiny Spinal Tap), která bych si při pohledu zpět přál, aby mi někdo dal, když jsem s kybernetickou bezpečností sám historicky začínal. Doplním, že tyto body samozřejmě odrážejí jen můj osobní pohled a názory. A byť si za vším níže uvedeným stojím, pokud se jakýkoli bod bude rozcházet s vaším pohledem na věc, nebudu vám to mít za zlé…

  1. Bezpečnost vždy závisí na lidech, procesech a technologiích – v tomto pořadí. Nikdy na to nezapomínejte, ani pokud vás vaše profesní působení dovede k prodeji bezpečnostních technologií nebo do bezpečnostního managementu. Snaha o zajištění bezpečnosti nákupem softwarových nebo hardwarových systémů, o které se nemá kdo starat, je cesta k velmi snadnému splnění checklistů ověřujících existenci bezpečnostních opatření, ale reálný přínos něčeho takového bude vždy velmi omezený, neb technologie samy o sobě rozumnou úroveň bezpečnosti nikdy v žádném prostředí nezajistí.
  2. Buďte obezřetní vůči samozvaným autoritám. V odborné komunitě máme mnoho odborníků hodných označení autorita, tedy extrémně šikovných a kompetentních lidí, kteří jsou obecně uznávaní (a také mnoho šikovných a kompetentních lidí, o kterých bohužel nikdo mimo jejich blízké okolí neví).
    Máme v ní ale i řadu těch, kteří jsou za „autority“ považováni jen proto, že se tak sami prezentují, neb se bezpečnosti věnují dlouho a jsou v nějakém smyslu hodně hlasití nebo jsou hodně vidět. Reálné odborné – tím spíše technické – znalosti těchto lidí jsou ale mnohdy jen velmi omezené. Problém není v tom, že by tito lidé byli uznávaní víc, než si zaslouží, ale že v důsledku své omezené odbornosti mnohdy šíří myšlenky, které jsou již překonané, nebo dokonce myšlenky, které mohou být aktivně škodlivé. Je proto vhodné dobře zvažovat, v jakou „autoritu“ budeme vkládat naši důvěru. Dobrým testem odbornosti těch, kteří jsou hodně vidět, je podívat se kriticky na odbornou hloubku jejich publikovaných výstupů. Jsou-li veškeré články dané osoby, témata jejích konferenčních příspěvků nebo obsahy vystoupení v médiích plná výhradně obecných proklamací bez skutečné hloubky (tedy například standardní mantry typu „musíme řídit rizika“, „musíme vzdělávat uživatele“, nebo – nedej bože – „musíme zajistit zero-trust“), máme k dispozici poměrně jasný ukazatel odborné úrovně dané osoby. Shrnuto a podtrženo, i v naší profesi bohužel platí, že nejhlasitější hlasy nejsou nezbytně ty nejkvalifikovanější…
  3. Neprezentujte se jako „experti na kybernetickou bezpečnost“. Nikdy. Bez ohledu na to, jak dobré si budete myslet, že máte znalosti, a bez ohledu na „expertní“ certifikace, které možná v průběhu své kariérní cesty získáte. Nejen proto, že jako lidé nejsme schopní být vůči sobě samým plně objektivní (pamatujte na práci pánů Dunninga a Kruegera), ale i proto, že kybernetická bezpečnost je dnes již extrémně širokou odbornou oblastí a skutečnou expertízu v celé její šíři – od detailů konfigurace firewallů, přes procesy pro zvládání incidentů, techniky reverzního inženýrství, metodiky pro kvantitativní analýzu rizik, mechanismy digitální forenzní analýzy, ofenzivní postupy pro red teaming až po zabezpečení OT nebo specifika bezpečnostní architektury aplikací – už tak dnes nemůže mít v podstatě nikdo.
    Pokud se navíc experty v jakékoli dílčí oblasti kybernetické bezpečnosti někdy stanete, nebojte se – začnou vás tak bezpochyby označovat jiní…
  4. Neignorujte bezpečnostní vzdělávání mimo svou primární oblast zájmu. Specializace na jednu konkrétní oblast kybernetické bezpečnosti je naprosto v pořádku a pro většinu profesionálů je dokonce žádoucí. Určitý základní všeobecný přehled o kybernetické bezpečnosti jako celku by však měl být standardem pro jakéhokoli bezpečnostního specialistu – přinejmenším proto, že mu může poskytnout hodnotný kontext pro jeho vlastní profesní aktivity. Aneb aby mohl svou práci dělat skutečně odborně na výši, i systémový inženýr nastavující firewally by měl mít alespoň obecnou představu o tom, že v oblasti kybernetické bezpečnosti existuje nějaká legislativa (neb ta může determinovat kdy a kde mají/musí být firewally použity), a penetrační tester by měl mít tušení o tom, jak funguje bezpečnostní dohled v rámci SOC (neb pro něj může být v případě neohlášených testů potenciálně žádoucí vyhnout se detekci).
  5. Pokud se vaší specializací stane technologické řešení určitého výrobce – například firewally od společnosti Checkpoint nebo EDR/XDR řešení od Microsoftu – nikdy si nedovolte padnout do mentálního nastavení, v němž byste danou technologii považovali za ideální. Žádný firewall, SIEM, WAF ani EDR/XDR není plošně „nejlepší“ a nemá smysl něco takového tvrdit, ani kdybychom danou technologii prodávali…
  6. Vysoká pozice negarantuje odbornost a nízká pozice její absenci, nesuďte tedy profesní kolegy jen dle jejich titulů a – konec konců – ani dle odborných certifikací, které mají. V praxi se v kybernetické bezpečnosti setkáte se spoustou velmi chytrých a kompetentních lidí bez jakýchkoli certifikací na všech pozicích, od juniorních po manažerské, stejně tak ale můžete ve všech těchto pozicích potkat i řadu lidí ověnčených certifikacemi a přesto vykazujících velkou míru amatérismu a neznalosti.
  7. Nevěřte, že nějakou oblast bezpečnosti skutečně znáte, pokud jste jí do detailu viděli jen v jedné organizaci. Ani vidět jednu oblast (bezpečnostní monitoring, řízení rizik, penetrační testování, apod.) do detailu v řadě podobných organizací nebo řadě různých organizací působících ve stejném regionu nebo ve stejném sektoru vám nemůže dát skutečně hluboké povědomí o tom, jak může/má být daná oblast řešena všeobecně, nebo jak bývá řešena v jiných regionech či sektorech.
  8. Váš čas je drahý a měli byste si důsledně vybírat, čemu jej budete věnovat. Pokud se tedy budete chtít vzdělávat a nebudete mít jen touhu hledat další vhodný bezpečnostní produkt nebo službu pro vaše prostředí, dobře si vybírejte konference, kterých se budete účastnit. Převážná většina rádoby odborných konferencí je totiž ve skutečnosti převážně marketingově, nikoli odborně orientovaná, a prezentace v rámci nich mají často za cíl ne vzdělat posluchače, ale přesvědčit je, že produkt firmy X nebo služba firmy Y je to, co si nezbytně potřebují pořídit, aby byla jejich organizace v bezpečí.
  9. Pokud chcete pracovat v kybernetické bezpečnosti a nemáte alespoň základní technické znalosti, získejte je, neb bez nich nebudete schopní vykonávat žádnou bezpečnostní pozici skutečně efektivně.
    Výše uvedené nemá vyznívat jako gatekeeping, nebo naznačovat, že by každý CTI analytik, manažer kybernetické bezpečnosti nebo specialista řízení rizik měl být schopný psát exploity, hledat zero-day zranitelnosti nebo detailně analyzovat síťový provoz. Pokud ale ti, kteří zastávají výše zmíněné role, nebudou znát ani absolutní technické základy typu jaký je rozdíl mezi TCP a UDP a proč je tento rozdíl relevantní pro funkci firewallů, co je to Active Directory a co by principiálně znamenala kompromitace účtu doménového administrátora, či jak konceptuálně funguje EDR nebo SIEM a jaké škodlivé chování po „vybalení z krabice“ tyto systémy zřejmě dokáží a nedokáží detekovat, nemohou svou práci vykonávat skutečně efektivně a kvalitně.
    Z úst mnohých zástupců vzdělávacích organizací i vybraných firem v posledních letech často zaznívá, že kybernetické bezpečnosti se může profesně věnovat v podstatě kdokoli, bez ohledu na předchozí vzdělání či znalosti. Tato myšlenka je do jisté míry platná, má však své významné limity – kdokoli se může ZAČÍT profesně věnovat kybernetické bezpečnosti, ale určitě ne kdokoli může v této profesní oblasti následně i dlouhodobě smysluplně působit.
    Pravdou je, že ne každý bezpečnostní specialista musí mít za sebou předchozí odborné vzdělání zaměřené na kybernetickou bezpečnost, aby mohl svou práci dělat dobře. Rozdílný znalostní background může být u některých rolí (např. těch zaměřených na CTI) dokonce žádoucí a junior bez předchozího IT vzdělání či odborné praxe se tak určitě může v bezpečnosti smysluplně uchytit.
    Pokud si ale takový člověk velmi rychle neosvojí alespoň základní technické povědomí, nebude z principu schopný dodávat svému zaměstnavateli a/nebo zákazníkům výstupy s jakoukoli odbornou hodnotou, a to i kdyby se měl věnovat jen procesním aspektům kybernetické bezpečnosti. Přeci jen nemůžeme smysluplně řídit kybernetická bezpečnostní rizika spojená se škodlivým kódem, nebo psát bezpečnostní směrnice a politiky zaměřené na ochranu před touto hrozbou, pokud nemáme nejmenší tušení, jak vlastně takový škodlivý kód obecně funguje a „malware“, „virus“, „trojan“ a „červ“ jsou pro nás jen jakési vágní, mlhou zahalené termíny s de facto ekvivalentním významem, a „C2“ chápeme jen jako označení pole na šachovnici.
  10. Nevěřte všemu, co je psáno. Odborná i populární literatura, ale také kurzy a materiály pro přípravu k certifikačním zkouškám (i ty oficiální) bohužel relativně často obsahují vedle technických fakt i řadu marketingových tvrzení a osobních názorů prezentovaných jako fakta. Nezřídka pak v těchto materiálech potkáte vedle pravdivých informací i řadu polopravd a chyb. Odlišit technická fakta od marketingu a chybné od pravdivého vyžaduje určitou odbornost a ne vždy tak budete něčeho takového schopní. Pokud se vám nicméně bude zdát, že to, co jste si právě přečetli, možná nebude v pořádku, raději nespoléhejte na jediný informační zdroj a dané informace si ověřte jinde.
  11. Připravte se na to, že kybernetická bezpečnost v jakékoli organizaci, v níž budete působit, bude mít slabá místa, která se vám nebudou líbit. Pokud nebudete vlastníky či manažery organizací, v nichž budete působit, vaším úkolem nebude fakticky nikdy zajistit kybernetickou bezpečnost dané organizace, ale snažit se pomoci dané organizaci fungovat co nejbezpečněji v mantinelech vytyčených jejími vlastníky či managementem. Je to totiž právě management, kdo je finálně zodpovědný za zajištění fungování organizace a vlastní i všechna s tím spojená rizika – včetně těch bezpečnostních. Naší rolí z pozice bezpečnostních specialistů je pomoci managementu správně tato rizika vyhodnocovat a řídit.
    Pokud tedy budete v rámci své praxe vnímat nějaké slabé místo organizačních procesů či technologické infrastruktury nebo určitou hrozbu jako vysoce relevantní pro organizaci, v níž budete působit, je žádoucí na ně upozornit. Pokud se management dané organizace následně rozhodne riziko spojené s těmito faktory akceptovat bez doplnění technických nástrojů, personálu nebo procesních opatření, která jste doporučili a která byste na základě vlastního odborného zhodnocení považovali za vhodná, nevěšte hlavu. Byť to není vždy příjemné, finální rozhodnutí o bezpečnosti má management organizace – my jako bezpečnostní specialisté můžeme jen radit, ukazovat cestu a snažit se dělat maximum v rozsahu kompetencí, které jsou nám svěřeny – taková je (mnohdy smutná) realita našeho oboru.

Desatero pro začínající specialisty na kybernetickou bezpečnost

celý članek

CEE Hub: Tři roky růstu, učení a regionálního dopadu

26.
března
Wikimedia ČR

Předmluva k českému překladu článku

Přinášíme vám překlad článku Jessicy Stephenson, původně publikovaného v angličtině na blogu Diff, který shrnuje tři roky fungování CEE Hubu – iniciativy, která zásadně proměňuje podobu spolupráce v regionu střední a východní Evropy. Pro Wikimedia Česká republika má tento příběh zvláštní význam: byli jsme u jeho vzniku a dlouhodobě se podílíme na jeho rozvoji.

Zisiadis Nikolaos, CC BY-SA 4.0, via Wikimedia Commons

Naše zapojení není pouze symbolické. Jako součást řídicího výboru a širší otevřené poradní skupiny Hubu se aktivně podílíme na jeho strategickém směřování, nastavování procesů i hledání cest, jak lépe podporovat spolupráci jednotlivců i celých komunity napříč regionem. Právě důraz na otevřenost, sdílení zkušeností, lidské vazby a vzájemnou podporu odpovídá hodnotám, které dlouhodobě rozvíjíme i v rámci našich programů v České republice – od vzdělávání přes komunitní aktivity až po mezinárodní spolupráci.

Velmi důležitou oblastí, na které se jako Wikimedia ČR v rámci CEE Hubu podílíme, je práce s mládeží a rozvoj budoucích lídrů a lídryň. Organizace první globální Wikimedia Youth Conference v Praze v roce 2025 ukázala, jak silný potenciál má mezigenerační spolupráce a jak důležité je vytvářet prostor, kde mohou mladí wikimediáni a wikimediánky růst, sdílet zkušenosti a aktivně se podílet na směřování celého hnutí.

Stejně tak přinášíme do regionální spolupráce zkušenosti s nízkoprahovými grantovými mechanismy a podporou komunitních iniciativ. Naše dlouhodobá práce s komunitními minigranty se stala inspirací i pro rozvoj grantových nástrojů v rámci Hubu a přispívá k tomu, aby se k financování dostávaly i menší nebo začínající komunity. V návaznosti na to vnímáme jako zásadní krok i letošní převzetí správy Rapid fondů od WMF, kde je klíčová právě znalost lokálního kontextu a potřeb komunit.

CEE Hub pro nás představuje důležitý nástroj pro posilování inkluze, diverzity a rovného přístupu ke zdrojům v celém regionu. Pomáhá vyrovnávat rozdíly mezi jednotlivými komunitami, podporuje jejich růst a zároveň vytváří prostor pro sdílenou identitu a spolupráci napříč hranicemi.

Z české zkušenosti víme, že i menší tým může mít velký dopad, pokud stojí na silné komunitě, důvěře a ochotě spolupracovat. Právě tyto principy dnes vidíme v praxi napříč celým regionem CEE – a je pro nás důležité být jejich součástí.

Věříme, že následující text vám pomůže lépe pochopit, jak CEE Hub funguje, jaké přináší výsledky a proč má jeho další rozvoj zásadní význam pro budoucnost svobodného sdílení znalostí.

Za Wikimedia Česká republika
Klára Joklová
výkonná ředitelka

Přehled vývoje CEE Hubu

CEE Hub logo, Kurmanbek, CC BY-SA 4.0, via Wikimedia Commons

Během pouhých tří let se CEE Hub (Střední a východní Evropa) stal klíčovým pilířem regionální spolupráce a podpory komunity. S celkovou investicí 565 000 USD a současným ročním rozpočtem 237 000 USD se Hub rozvinul v spolehlivé koordinační centrum propojující více než 40 komunit a afiliací různé velikosti, vyspělosti a kapacit.

Činnost Hubu ukazuje sílu decentralizovaných struktur vedených komunitou. Vznik Hubu byl umožněn dlouhodobou kulturou důvěry a spolupráce v regionu, akčně orientovaným přístupem, ochotou experimentovat a solidaritou mezi etablovanými afiliacemi a rozvíjejícími se komunitami.

BKlen-CEEhub (různí autoři a autorky
CC By-SA 4.0

Díky kombinaci jasné strategické vize, tří zaměstnanců a desetičlenného dobrovolnického řídicího výboru Hub prokázal svůj potenciál v několika klíčových oblastech: posilování zapojení mladých lidí, koordinace technologických potřeb, podpora růstu rozvíjejících se komunit, posilování obsahových kampaní afiliací, usnadňování přístupu ke zdrojům a budování pocitu sounáležitosti mezi wikimediány v regionu.

Posilování mladých dobrovolníků a budoucích lídrů

Díky systematickému mentoringu, rozvoji dovedností a projektům spoluvytvářeným s komunitou pomohl Hub proměnit počáteční experimenty v rostoucí ekosystém zaměřený na mládež.

CEE Youth Group vznikla právě díky aktivitám CEE Hubu a rozrostla se na 81 členek a členů z 23 zemí. Funguje jako podpůrné prostředí pro mladé nové editory a editorky i organizátory a organizátorky.

Významným milníkem byla první Wikimedia Youth Conference, která byla spolupořádána spolkem Wikimedia Česká republika. Zájem 223 mladých wikimediánů a wikimediánek vedl k účasti 83 lidí ze všech osmi globálních regionů. Konference se stala jedinečným prostorem, kde mladí dobrovolníci a dobrovolnice mohli sdílet společné výzvy, posilovat své sebevědomí a formulovat dlouhodobé cesty svého zapojení.

CEE Youth Group Yerevan Meeting 2025. Հակուլիկ, CC0, via Wikimedia Commons

Posilování adopce nástrojů a regionální technologické spolupráce

Dobrovolnicky vedená pracovní skupina Tech Advancement při Hubu se zaměřila na zlepšení dostupnosti nástrojů, jejich dokumentace, propojování vývojářů a vývojářek pro podporu údržby a také na experimentování s iniciativou zaměřenou na zvýšení využívání nástroje Cat-a-lot.

Tento kolaborativní přístup je vnímán jako regionální model pro budování kapacit v oblasti technologického poradenství.

„Jsem nadšená, že vidím tento typ uvažování z regionu, protože odráží přístup Product and Technology Advisory Council (PTAC) i současné pilotní aktivity Unsupported Tools Working Group…,“ uvedla Selena Deckelmann, Chief Product and Technology Officer ve Wikimedia Foundation, v souvislosti s CEE Hubem.

Díky užší spolupráci s Wikimedia Foundation Hub také podpořil rozšiřování nástrojů pro nováčky. Celkem 16 z 24 Wikipedií v regionu (64 %) nyní využívá funkci mentoringu a region CEE se podílí 11 % na všech dokončených doporučených editacích nováčky na celém světě. Tyto výsledky ukazují, že koordinovaná regionální podpora může výrazně urychlit adopci nástrojů i udržení nováčků.

Rozšiřování dopadu kampaní a komunitních programů

Kampaně zůstávají klíčovým nástrojem zapojování dobrovolníků a dobrovolnic napříč regionem CEE. Hub sehrál strategickou roli při oživování stávajících kampaní a pomáhal organizátorům a organizátorkám navrhovat efektivnější outreach, metodiky i školicí materiály.

Výrazným příkladem je kampaň CEE Spring. Po letech poklesu účasti v důsledku pandemie COVID-19 přispěla podpora Hubu k obnovení její dynamiky:

  • nárůst počtu vytvořených článků o 15 %
  • nárůst počtu přispívajících žen o 72 %
  • o 31 % více zapojených komunit
  • 157 nových přispěvatelek a přispěvatelů od roku 2022

Rozšíření o tematické podkategorie Human Rights a Youth v roce 2025 dále rozšířilo tematický záběr kampaně. Zapojení výzvy Coordinate Me na Wikidatech vedlo k výraznému nárůstu – počet editovaných položek vzrostl o 340 % oproti roku 2024. Z toho 30 % účastníků pocházelo ze zemí CEE a 38 % tvořili nováčci.

Vedle CEE Spring Hub podporoval také globální i regionální kampaně, jako jsou Wiki Loves Earth, Wiki Loves Monuments, iniciativy k Mezinárodnímu dni Romů nebo Wiki Loves Film. Tato podpora dlouhodobě vede k vyšší participaci, větší obsahové diverzitě a posilování kapacit lokálních komunit.

Hub rovněž pomohl nově vznikajícím komunitám uspořádat jejich první akce zaměřené na otevřené znalosti, čímž přispěl k budování partnerství v prostředích, kde je povědomí o projektech Wikimedia stále omezené.

Podpora rozvíjejících se komunit a akcelerace jejich růstu

Jednou z nejvýznamnějších rolí CEE Hubu je systematická podpora rozvíjejících se wikimediánských komunit. V roce 2024 Hub investoval do částečných pracovních úvazků v Řecku, na Kypru, v Rumunsku a Moldavsku.

Zisiadis Nikolaos, CC BY-SA 4.0, via Wikimedia Commons

Díky této podpoře:

  • v Rumunsku a Moldavsku vznikla akademická partnerství a Wikipedia byla integrována do univerzitních programů,
  • v Řecku a na Kypru byly vytvořeny strategické plány a podařilo se získat první roční granty.

Tyto kroky vedly k nárůstu počtu lokálních přispěvatelek a přispěvatelů, vzniku stabilních institucionálních partnerství a posílení kapacit těchto komunit. Zároveň je připravily na aktivnější roli v regionální spolupráci, včetně spolupořádání významných akcí, jako je CEE Meeting 2025.

Zlepšování přístupu ke zdrojům a posilování regionálního financování

CEE Hub začal hrát zásadní roli v podpoře rovného přístupu k financování. Jeho program mikrograntů, s rozpočtem 18 000 USD na dva roky, poskytl celkem 28 grantů, přičemž polovina z nich směřovala do komunit, které dosud nikdy nezískaly podporu od Wikimedia Foundation.

Tyto flexibilní a nízkoprahové granty pomohly nastartovat aktivity zaměřené na tvorbu obsahu, komunitní setkání i vznik nových dobrovolnických skupin. Přibližně 65 % podpořených aktivit se soustředilo na obsah a editaci, což vedlo k zapojení více než 330 editorů a editorek a ke vzniku více než 9 000 obsahových příspěvků. (Více informací najdete na Diff blogu.)

Hub zároveň podpořil 11 z celkových 54 žadatelů o Rapid Fund v regionu, a to prostřednictvím praktické podpory při přípravě žádostí. Tato podpora přinesla konkrétní výsledky:

  • nárůst objemu Rapid Funds v regionu o 26 %
  • 5 nových komunit úspěšně získalo financování
  • 90 % podpořených žádostí bylo schváleno (oproti běžným cca 75 %)
  • větší diverzifikaci aktivit – včetně budování partnerství, spolupráce s GLAM institucemi a tvorby vzdělávacích toolkitů

„Celý tým byl investovaný do našeho úspěchu, což bylo velmi povzbuzující,“ uvedl jeden z členů komunity podpořené při přípravě grantové žádosti.

„Rapid grant je náročnější, zejména pro méně zkušené žadatele – zahrnuje více dokumentace a otázek a celý proces trvá déle. Mikrogranty pomáhají tuto zkušenost budovat, jsou prvním krokem k získání větších grantů,“ uvedl příjemce mikrograntu.

V roce 2026 převezme Hub novou roli přímého správce Rapid Funds pro region, což umožní kontextově citlivější a efektivnější přidělování prostředků.

Kromě interního financování v rámci hnutí Wikimedia Hub také inicioval kroky k získávání externích zdrojů – například z EU, programu Erasmus, USAID nebo Swedish Institute. To představuje důležitý krok směrem k dlouhodobé finanční udržitelnosti.

Budování zapojení, propojenosti a sdílené identity

Zisiadis Nikolaos, CC BY-SA 4.0, via Wikimedia Commons

Výzkum online komunit dlouhodobě ukazuje, že „lidé se ochotně zapojují do prostředí, která nabízejí smysluplné a odměňující vazby“. CEE Hub tyto kontaktní body úspěšně vytváří. Prostřednictvím newsletteru (160 měsíčních zobrazení), setkání CEE Catch-Up a sdílených dokumentačních prostor pomáhá dobrovolníkům a dobrovolnicím zůstat v obraze o regionálním i globálním dění. Během dvou let přispěli dobrovolníci a dobrovolnice do newsletteru více než 175 články.

Zpětná vazba od příjemců grantů ukazuje výrazný nárůst pocitu uznání a propojení s hnutím Wikimedia díky aktivitám Hubu.

Hub sehrává také stabilizační roli při organizaci každoročních CEE Meetingů. Podporuje výběrová řízení na pořadatele a poskytuje mentoring novým organizátorům a organizátorkám, čímž přispívá ke kvalitnímu průběhu akcí, silným programům i vytvoření prostoru pro náročná témata, včetně otázek rovnosti v zapojení a reprezentaci.

V každodenní praxi Hub často funguje jako „lidský kontaktní bod“, na který se mohou členky a členové komunity obracet s konkrétními potřebami a získat rychlou, kontextově citlivou podporu – a zároveň se propojit s Wikimedia Foundation nebo dalšími aktéry hnutí.

„Lidé potřebují vědět, na koho se mohou obrátit, a že dostanou odpověď během dní nebo i hodin. Už samotné vědomí, že podpora existuje, může motivovat k zapojení.“

— Barbara Klen, koordinátorka CEE Hubu

V neposlední řadě Hub podnikl důležité kroky k vytvoření transparentního, reprezentativního a komunitně řízeného systému správy. Na základě získaných zkušeností a zpětné vazby začíná testovat nový model výběru členů a členek Steering Committee se zapojením komunity a strukturovanější proces účasti komunity v šesti pracovních skupinách.

Těšte se na rok 2026!

celý članek

Deska Powerboard Tyche Desktop je připravena pro výrobu prototypů

25.
března
ALT-F4

Návrh desktopové základní desky Powerboard Tyche, která má být mezikrokem v (doposud neúspěšné) tvorbě zcela nového open-source notebooku založeného na architektuře PowerPC, došel do takového stádia, že je možné přikročit k výrobě prvních prototypů.

Výrobcem bude italská společnost ACube Systems, která PowerPC systémy vyrábí již takřka dvacet let a podílela se i na vývoji této desky. Prvních pět prototypových kusů bude stát zhruba 9000 €, na což bude zapotřebí vybrat příspěvky od podporovatelů. Pokud je možné z webu projektu vyčíst, pak se ještě nevybrala ani plná částka na samotný návrh, takže je otázkou, zda se ambiciózní deadline stanovený na duben 2026 (již posunutý z původně uvažovaného konce října loňského roku), podaří dodržet.

Zdroj:

Jak k celému tomuto projektu prohlásil přední český amigista: 

Vzdycky kdyz zjistim ze furt se pracuje na PPC notebooku tak se musim usmat :)

Já sice nejsem až takový škarohlíd, ale i tak si uvědomuju, že až dokončí tento úctyhodný desktopový projekt a začnou prodávat nějaké skutečné desktopové desky, budou s hlavním cílem - tedy PowerPC notebookem - takřka přesně tam, kde byli před patnácti lety, tj. nikde.

celý članek

Implementace AI v korporátu

24.
března
Táta vaří kafe

Michal Bočvarov – Dopravní podnik Ostrava
14. 4. 2026 – úterý
17:30 - 19:00 – 18:00 espresso note
Máma mele kafe – Hrnčířská 3, Opava

Skutečné příběhy ze zavádění AI ve firmách. Jak uklidnit CEO, rozhýbat tým a vše mezi tím. Od obav a buzzwordů k reálnému používání.

celý članek

Hyperion Entertainment a Amiga Corporation pozastavily vzájemné soudní spory

23.
března
ALT-F4

Ačkoliv se to může zdát k nevíře, i takřka dvaatřicet let po krachu Commodore a první z řady komerčních smrtí Amigy, je tato předmětem soudních sporů společností, které se různými cestami osudu pasovaly do pozice udržovatelů této platformy. Dvě z nich - belgický Hyperion Entertainment CVBA, který má na svědomí vývoj AmigaOS 4 a AmigaOS 3.2, a Amiga Corporation, která vznikla přejmenováním z C-A Acquisition Corp., která pro změnu získala práva na značku Amiga od zaniklé Amiga Inc. - se po soudech tahají už takřka dvacet let.

Na seznam jejich vzájemných dohod a mimosoudních vyrovnání se aktuálně přidala další položka: obě společnosti se dohodly, že pozastaví vzájemné soudní spory a jednání nadále povedou v obchodní a ne legální podobě. Prozatím bylo konstatováno, že Amiga Corporation potvrzuje platnost licence operačního systému pro Hyperion, který smí nadále systém rozvíjet a distribuovat, finanční stránka věci se nadále řeší.

Tento krok mimo jiné Hyperion Entertainment umožňuje šířit AmigaOS 3.2 digitálně, což se také ihned stalo.

Zdroje:

Že jim to stojí za to. Chápu, že z retro komunity se dají na Amize stále vytřískat nemalé prachy, ale Hyperion tady pracně roky vyvíjí systém pro pár nadšenců, kteří ho ve skutečnosti chtějí používat a ne si jen v sobotu večer zahrát Putty Squad či Turricana, a pohrobci kdysi slavné Amiga Inc., kteří vznikají a zanikají jako na běžícím pásu, jim pořád hážou klacky pod nohy.

celý članek

#1 – Budou nás superpočítače operovat místo lékařů?

23.
března
VUT - Technicky vzato (podcast)

Ještě nedávno byly některé vědecké úlohy prakticky neřešitelné, jelikož chyběla dostatečně výkonná technologie, která by to zvládla. Dnes to mění superpočítače. Umí simulovat vesmír, předpovídat počasí nebo pomáhat lékařům s plánováním operací. Superpočítače totiž umožňují vytvářet detailní simulace lidského těla a díky nim vytvářet zákroky na míru konkrétním pacientům. Výsledkem je personalizované léčba, která je přesnější, rychlejší a šetrnější k pacientům i efektivnější pro lékaře. A právě využitím superpočítačů v medicíně se zabývá odborník Jiří Jaroš z Fakulty informačních technologií VUT. 🩺💻

Jak superpočítače fungují? Nemůžou lékaře zmást? Jak do toho všeho vstupuje umělá inteligence? A může se nakonec fiktivní centrální mozek lidstva stát skutečností?

Timeline epizody:

01:32 – Co je to superpočítač a jak funguje
03:47 – Superpočítače a jejich využití v praxi
07:11 – Personalizovaná medicína
13:50 – Superpočítače a propojení s AI
20:47 – Jak jsme na tom se superpočítači v České republice
23:16 – Budoucnost technologií a role člověka

celý članek

Používáme lopatu tam, kde jsme měli bAGRT

23.
března
Česká komunita MojeFedora.cz

Úvod

Nedávno se u Workstation SIG objevil návrh odstranit z GNOME nástroj pro hlášení pádů aplikací jménem ABRT. Přiznám se, že mě to trochu zamrazilo. ABRT totiž patřil k věcem, které ve Fedoře fungovaly až podezřele pohodlně. Když aplikace spadla, stačilo pár kliknutí a nástroj sám prozkoumal coredump, vytvořil backtrace a připravil hlášení do Bugzilly.

ABRT byl zkrátka takový bagrt. Stačilo mávnout na řidiče, bagrt hrábl lžící, nabral všechno potřebné a odvezl to rovnou k vývojářům. Jenže teď je bagrt pryč.

Možná se porouchal, možná na něj už nikdo nemá čas, možná se jen nevešel do nových plánů. Ať tak nebo tak, když dneska chceme zjistit, proč aplikace spadla, nezbývá než si plivnout do dlaní a vzít do ruky lopatu. Naštěstí je to docela dobrá lopata a jmenuje se coredumpctl. V tomto článku si ukážeme, jak se s ní správně rozmáchnout, abychom mohli nahlásit pád aplikace stejně dobře, jako dříve s ABRTem.

Co je coredumpctl a co dělá?

coredumpctl je nástroj v linuxových distribucích, který slouží ke správě a analýze záznamů o pádech aplikací (core dump). Je součástí ekosystému systemd a pracuje nad službou systemd-coredump, která automaticky zachycuje pády programů.

Když aplikace v Linuxu havaruje, například kvůli segmentation fault, může systém vytvořit core dump. To je soubor obsahující snímek paměti procesu v okamžiku pádu. Tento soubor je velmi užitečný pro vývojáře, protože umožňuje zpětně analyzovat, co program dělal těsně předtím, než definitivně vypustil duši. Coredumpctl nám umožňuje tyto záznamy:

  • zobrazit seznam všech zaznamenaných pádů aplikací
  • zobrazit informace o konkrétním pádu (PID, čas, program, signál)
  • uložit core dump do souboru
  • automaticky otevřít dump v debuggeru gdb

Ověříme, že záznam o pádu vznikl

Po pádu aplikace, máme-li štěstí, se uloží záznam o pádu aplikace. Tyto záznamy si můžeme vypsat a zjistit, zdali se uložil i ten, který nás zajímá:

coredumpctl list

Tento seznam může vypadat třeba nějak takto.

TIME                           PID  UID  GID SIG     COREFILE EXE                     SIZE
Thu 2025-11-13 09:50:10 CET   5341 1000 1000 SIGABRT missing  /usr/bin/gnome-shell       -
Thu 2025-12-18 23:15:51 CET   5238 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Mon 2025-12-29 23:20:13 CET   4867 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Wed 2025-12-31 09:30:18 CET  13705 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Wed 2025-12-31 18:36:36 CET   5907 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -
Sat 2026-01-03 17:53:33 CET   4888 1000 1000 SIGABRT missing  /usr/bin/gnome-software    -

Když by byl seznam příliš dlouhý a pokud víme, jak se jmenuje aplikace, která spadla, můžeme výstup omezit příkazem:

coredumpctl list <nazev_binarky>

Pokud znáte přibližný čas pádu, pomůže filtr „od“:

coredumpctl list --since "2026-02-16 13:00:00"

Nás budou v získaném seznamu zajímat především tyto čtyři sloupce: TIME, PID, COREFILE a EXE. Čas je samozřejmě jasný a můžeme se podle něj snadno orientovat, PID je identifikátor spadnutého procesu a je pro nás nejdůležitější. COREFILE ukazuje, zda máme k záznamu nějaká data. V našem případě vidíme, že všechna jsou missing, tedy pro tyto pády žádná data nemáme a už nebude možné core dump ze systému získat.

Core dumpy jsou mnohdy veliké soubory, a proto je systém po nějaké době odstraňuje. V defaultním nastavení se core dumpy odstraní, jakmile zabírají 10 % diskového prostoru nebo maximálně 4 GB. V konfiguračním souboru coredump.conf si můžeme nastavit proměnnou MaxUse=20GB a v tom případě se core dumpy v systému udrží déle, protože jim dovolíme zabrat až 20 GB. Více se dočtete v manuálových stránkách, tedy man coredump.conf. Budeme si pamatovat, že když nám aplikace spadne a my chceme pád ohlásit, musíme core dump zpracovat co nejdříve. Pokud sloupeček obsahuje hodnotu present, máme vyhráno.

Sloupec EXE pak ukazuje název spustitelného souboru procesu, který spadl, a právě tam můžeme zjistit jméno aplikace pro filtrování daného seznamu, o kterém jsme se zmínili výše.

Prohlédneme detaily záznamu

Z výpisu si vezměte PID nebo ID, které coredumpctl zobrazuje, a vypište detaily:

coredumpctl info <PID>

Zkontrolujte hlavně EXE, Command Line a Timestamp. Pokud nesedí, vraťte se a vyberte jiný záznam.

Informace z tohoto příkazu jsou také jediné informace, které o pádu dostanete, pokud už systém stačil záznamy odklidit. Nemáte-li však k dispozici nic lepšího, nahlašte bug tak jako tak a přiložte alespoň výpis tohoto příkazu. I to může leckdy stačit.

Ukládáme coredump do souboru

Systemd-coredump ukládá dump interně, ale vy ho snadno vyexportujete do souboru:

coredumpctl dump <PID> -o core.<PID>

Ověřte velikost, protože coredumpy bývají velké:

ls -lh core.<PID>

Pozor však na bezpečnost. Coredump je paměť procesu, ve které se mohou nacházet hesla, tokeny, cookies, části dokumentů, URL s parametry nebo další osobní data. Nenahrávejte tedy coredump nikdy na veřejná úložiště, pokud si nejste absolutně jistí tím, že je vše v pořádku. Přikládejte coredump teprve tehdy, když si ho vývojáři vyžádají, a i tak jen přes soukromé kanály. K nahrání do Bugzilly slouží tzv. backtrace či stacktrace.

Komprimujeme coredump a šetříme naše lesy

Pro issue tracker je praktické coredump komprimovat. Například nástroj xz mívá výborný poměr komprese:

xz -T0 -9 core.<PID>

Pokud chcete rychlejší kompresi za cenu většího souboru:

xz -T0 -3 core.<PID>

Získáváme textový backtrace

Vývojáře často zajímá backtrace víc než samotný coredump a také jsme si řekli, že je bezpečnější posílat právě ten. Získáme jej tak, že zapneme debugger pro proces, ze kterého chceme backtrace vygenerovat:

coredumpctl debug <PID>

Tento příkaz spustí gdb. Hned po startu se nás debugger zeptá, jestli chceme použít debuginfod, což umožní debuggeru stahovat metadata pro debugovací proces automaticky z databáze, a nemusíte tak instalovat mnoho debugovacích balíčků. Stažené symboly se ukládají do ~/.cache/debuginfod_client/ a časem se tam může nashromáždit docela hodně dat, takže je vhodné ten adresář občas promazat.

Proces debugování spustíme pomocí následujících příkazů:

set pagination off
thread apply all bt full
quit

Pokud chceme backtrace uložit přímo do souboru, nastavíme přesměrování do onoho souboru příkazem set logging a pak teprve provedeme samotné debugování:

set pagination off
set logging file backtrace.<PID>.txt
set logging on
thread apply all bt full
set logging off
quit

Když se coredump neobjeví

Někdy aplikace spadne, ale coredump se ve výpisu neobjeví a není tak co prozkoumávat. Mezi nejčastější důvody patří:

  1. Aplikace neskončila tzv. signálem. Pokud proces nespadl signálem typu SIGSEGV nebo SIGABRT, nebo pokud byl takový pád ošetřený v samotné aplikaci, nemusí se coredump vytvořit.
  2. Vytváření coredumpů je vypnuté limitem. Zkontrolujte ulimit -c.Hodnota 0 znamená nulový prostor pro coredump, a tak jej kernel vůbec nevytvoří. Dočasně lze pro aktuální shell zapnout: ulimit -c unlimited,případně nastavte limit systémově v souboru /etc/security/limits.conf.
  3. Limity a úložiště v systemd-coredump. Podívejte se docat /etc/systemd/coredump.conf

Důležité bývá Storage a velikostní limity, například ProcessSizeMax, ExternalSizeMax a MaxUse.

Co přiložit k reportu?

Minimum, které téměř vždy urychlí řešení:

  • Backtrace všech vláken: thread apply all bt full
  • Verze balíčku: rpm -q nazev_balicku
  • Verze Fedory: obsah /etc/os-release
  • Reprodukční kroky: co přesně jste spustili nebo klikli, případně vstupní data

Coredump jako soubor přikládejte až tehdy, když je to nezbytně nutné, ideálně po domluvě s maintainery.

Závěr

V tomto článku jsme si ukázali, jak je možné pokračovat ve sbírání informací o pádech aplikací i poté, co ABRT z Fedory zmizí. A že to vlastně není ani tak moc těžké.

Nezbývá než doufat, že lidé i přes menší pohodlí nepřestanou problémy hlásit, protože open source je tradičně věcí nás všech a jak víme, více hlav víc ví a více rukou více udělá. Koneckonců se ještě pořád může najít šikovný mechanik, který ten bagr opraví a namaže k všeobecné spokojenosti.

Publikováno pro mojefedora.cz. Tip: Pokud používáte debuginfod a cache narostla, typicky ji najdete v ~/.cache/debuginfod_client/ a můžete ji bezpečně smazat.

celý članek